4.1. xvif/outie basics

The basic ideas behind Outie are pretty simple:

• Outie is all about defining assertions.

• These assertions are schema validations applied on instance documents.

• These instance documents can be the instance document presented for validation, other documents, or results of transformations.

• Assertions about the same instance can be grouped into rules.

The basic building blocks of an Outie framework are rules. Each rule is about checking one and only one instance document. By default this instance document is the instance document presented for validation.

Other instance documents may be selected inline, by specifying a transformation to apply on existing instance or by reference, through a URL or reference to a variable. Global variables may be defined to store the result of transformation.

Rules may belong to a "mode" and rules for a mode are explicitly applied. Outie is purely declarative and side effect free: rules and variable definitions may appear in any order; the order in which rules and assertions are processed is not guaranted; variables which are not used may never been evaluated.

4.2. XVIF/Outie example

Here's an example that shows most of the features. We define that a document is valid if and only if it is valid after transformation by "normalize1.xsl" per the schemas "schema1.sch" and "schema1.rng" or if it is valid after transformation by "normalize2.xsl" per the schemas "schema2.sch" and "schema2.rng".

A framework to express this, using a variable to store the result of the transformation by "normalize2.xsl", could be:

 <?xml version="1.0" encoding="utf-8"?>
 <framework>
  <rule>
   <assert>
    <choice>
     <apply-rules mode="mode1"/>
     <apply-rules mode="mode2"/>
    </choice>
   </assert>
  </rule>
  <rule mode="mode1">
   <instance>
    <transform transformation="normalize1.xsl"/>
   </instance>
   <assert>
    <isValid schema="schema1.sch"/>
    <isValid schema="schema1.rng"/>
   </assert>
  </rule>
  <rule mode="mode2" instance="$instance2">
   <assert>
    <isValid schema="schema2.sch"/>
    <isValid schema="schema2.rng"/>
   </assert>
  </rule>
  <variable name="instance2">
    <transform transformation="normalize2.xsl"/>
  </variable>
 </framework>

4.3. More XVIF/Outie features

We have seen most of the features of Outie in this first example, let's review some of the more "hidden" aspects.

• Outie is purely declarative and side effect free:

  • Rules and variable definitions may appear in any order.

  • The order in which rules and assertions are processed is not guaranted.

  • Variables which are not used may never been evaluated.

• The tools to apply for a transformation or schema validation is implicit.

  • The choice of the tool is function of the document type.

  • The document type is assumed from the extension of the document.

  • Implementations need to provide a way to define the match between extensions and tools.

• Schemas can also be the result of transformations.

To illustrate this last point, we can take the example of a schema created by the "getStage" transformation proposed by Bob DuCharme:

 <?xml version="1.0" encoding="utf-8"?>
 <framework>
  <rule>
   <assert>
    <isValid>
     <schema>

      <transform extension=".xsd" 
         instance="schema.xsd"
         transformation="getStage.xsl">
        <with-param name="stageName" 
          select="'final'"/>
      </transform>

     </schema>
    </isValid>
   </assert>
  </rule>
 </framework>

Or, using a variable:

 <?xml version="1.0" encoding="utf-8"?>
 <framework>
  <variable name="final">

   <transform extension=".xsd" 
      instance="schema.xsd"
      transformation="getStage.xsl">
    <with-param name="stageName" 
      select="'final'"/>
   </transform>

  </variable>
  <rule>
   <assert>
    <isValid schema="$final"/>
   </assert>
  </rule>
 </framework>

4.4. Perspectives

The intention for Outie is to get the approval of the ISO DSDL working group and, ultimately, to become an ISO DIS (Draft International Standard).

But first some issues need to be fixed:

• Some transformations may split an instance document into several pieces, how do we address the different pieces in this case?

• Should the format of the validation report be specified?

• Should the format of the configuration file matching extensions and tools be specified?

More issues will probably be raised during the ISO meetings in London (May 2003), held during the XML Europe conference.