Rick Jelliffe gives the following description of his proposal:

A couple of short examples will be better than a long explanation...

 <schemachine xmlns="....">
  <title>Example Schema</title>
  <pass>
   <validate engine="schemachine:xsd" />
   <validate engine="schemachine:schematron">
    <param name="schema" href="a Schematron schema"/>
   </validate>
  </pass>
 </schemachine>

This first example passes a document through a W3C XML Schema validation followed by a Schematron validation.

 <schemachine xmlns="....">
  <title>Another Example Schema</title>
  <ns prefix="html" url="..." />
  <pass>
   <select engine="schemachine:namespace_selector">
    <param name="pattern">html:body</param>
    <output name="htmlbody" />
   </select>
   <validate engine="schemachine:relax_ng">
    <param name="schema" href="...."/>
    <param name="feasible">true</param>
    <input name="htmlbody"/>
   </validate>
  </pass>
 </schemachine>

Here, the document is passed through a "selector" which will select the html:body element and the output of the selection is used as the input of a Relax NG validation.

Rick Jelliffe has used all his experience to carefully craft a proposal with all the features needed to validate the more complex documents.

Some concepts such as phases are inherited from Schematron and Schemachine has all the bells ands whistles needed to fly:

XVIF is both very similar and very different from the approach taken by the Schemachine:

A first example of XVIF is:

 <?xml version="1.0" encoding="utf-8"?>
 <element xmlns="http://relaxng.org/ns/structure/1.0"
  xmlns:if="http://namespaces.xmlschemata.org/xvif/iframe" name="foo">
  <if:pipe>
   <if:transform type="http://namespaces.xmlschemata.org/xvif/regexp" 
                    apply="split/,/"/>
   <if:validate type="http://relaxng.org/ns/structure/1.0">
     <if:apply>
      <oneOrMore>
       <choice>
        <value>foo</value>
        <value>bar</value>
       </choice>
      </oneOrMore>
     </if:apply>
   </if:validate>
  </if:pipe>
 </element>

This is defining a Relax NG schema where the implicit "start" pattern is an element with name "foo" and which content is validated by a pattern "if:pipe", ie a micro-pipe of transformations and validations applied to all the elements, text nodes and attributes found in the "foo" element.

The pipe itself is a transformation splitting text nodes using the regular expression "," and a Relax NG validation applied on the result of this transformation.

A text node will thus be interpreted as a comma separated list of values and the list validates against a Relax NG schema expecting one or more values equal to "foo" or "bar".

The most basic building block of XVIF is "if:transform" to define a transformation:

 <!-- The context node-set "x" is defined by the host language here -->
 <if:transform type="URI identifying the nature of T">
   <if:apply>
      Implementation of T
   </if:apply>
 </if:transform>
 <!-- The result of the transformation "y=T(x)" is the context node-set here -->

A validation is a transformation which returns either its input or an error:

 <!-- The context node-set (x) is defined by the host language here -->
  <if:validate type="URI identifying the nature of V">
    <if:apply>
       Implementation of V
    </if:apply>
 </if:validate>
 <!-- The pipe is aborted if the result is false,
      otherwise, the context node-set is left unchanged -->

Transformations and validations can be chained in pipes:

 <if:pipe>
  <!-- The context node-set (x) is defined by the host language here -->
  <if:transform type="URI identifying the nature of T2">
    <if:apply>
       Implementation of T2
    </if:apply>
  </if:transform>
  <!-- The result T2(x) is the context node-set here -->
  <if:validate type="URI identifying the nature of V1">
    <if:apply>
       Implementation of V1
    </if:apply>
  </if:validate>
  <!-- The pipe is aborted with an exception if the validation fails.
       The context node is unchanged otherwise.  -->
  <if:transform type="URI identifying the nature of T1">
    <if:apply>
       Implementation of T1
    </if:apply>
  </if:transform>
  <!-- The result y=T1(T2(x)) is the context node-set her -->
  <if:validate type="URI identifying the nature of V">
    <if:apply>
       Implementation of V
    </if:apply>
  </if:validate>
 <!-- The result of the validation of y by V is the result of the pipe.-->
 <if:pipe>

That's all!

Another more complex example is a schema that may be used to validate dates split as three elements as W3C XML Schema dates:

 <grammar xmlns="http://relaxng.org/ns/structure/1.0"
  xmlns:if="http://namespaces.xmlschemata.org/xvif/iframe"
  datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
  <start>
   <if:pipe>
    <if:validate type="http://relaxng.org/ns/structure/1.0">
     <if:apply>
      <element name="date">
       <element name="year"><text/></element>
       <element name="month"><text/></element>
       <element name="day"><text/></element>
      </element>
     </if:apply>
    </if:validate>
    <if:transform type="http://www.w3.org/1999/XSL/Transform">
     <if:apply>
      <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
       <xsl:template match="/date">
        <xsl:copy>
         <xsl:value-of select="format-number(year, '0000')"/>
         <xsl:text>-</xsl:text>
         <xsl:value-of select="format-number(month, '00')"/>
         <xsl:text>-</xsl:text>
         <xsl:value-of select="format-number(day, '00')"/>
        </xsl:copy>
       </xsl:template>
      </xsl:stylesheet>
     </if:apply>
    </if:transform>
    <if:validate type="http://relaxng.org/ns/structure/1.0">
     <if:apply>
      <element name="date">
       <data type="date">
        <param name="minInclusive">2002-09-01</param>
        <param name="maxInclusive">2002-12-31</param>
       </data>
      </element>
     </if:apply>
    </if:validate>
   </if:pipe>
  </start>
 </grammar>

Note how we have chained a first validation making sure that the initial document looks like expected, a transformation and a second validation to check that the result of the transformation is a date.

The examples show up to now were simple and do not make much difference with a document approach such as Schemachine. There are a couple of reasons where micro-pipes are interested:

 <define name="csv">
  <if:pipe>
   <if:transform type="http://namespaces.xmlschemata.org/xvif/regexp" 
                    apply="split/,/"/>
   <if:validate type="http://relaxng.org/ns/structure/1.0">
     <if:apply>
      <oneOrMore>
       <choice>
        <value>foo</value>
        <value>bar</value>
       </choice>
      </oneOrMore>
     </if:apply>
   </if:validate>
  </if:pipe>
 </define>
 .../...
  <element name="foo">
   <ref name="csv"/>
  </element>

 <?xml version="1.0" encoding="utf-8"?>
 <grammar xmlns="http://relaxng.org/ns/structure/1.0" 
             xmlns:if="http://namespaces.xmlschemata.org/xvif/iframe">
  <start>
   <element name="foo">
    <choice>
     <group>
      <attribute name="type">
       <value>csv</value>
      </attribute>
      <ref name="csv"/>
     </group>
     <group>
      <attribute name="type">
       <value>list</value>
      </attribute>
      <list>
       <ref name="check-values"/>
      </list>
     </group>
    </choice>
   </element>
  </start>
  <define name="check-values">
   <oneOrMore>
    <choice>
     <value>foo</value>
     <value>bar</value>
    </choice>
   </oneOrMore>
  </define>
  <define name="csv">
   <if:pipe>
    <if:transform type="http://namespaces.xmlschemata.org/xvif/regexp" 
                     apply="split/,/"/>
    <if:validate type="http://relaxng.org/ns/structure/1.0">
     <if:apply>
      <ref name="check-values"/>
     </if:apply>
    </if:validate>
   </if:pipe>
  </define>
 </grammar>

In complicated cases, micro-pipes keep the transformations and validations close to the locations where they are needed. I think that this is important to insure the structure of the document is coded with a schema language instead of being a combination of selectors and bits of schemas.

Of course, these are only guesses and I don't think anyone has enough experience to have the final word in this debate!

One of the first concerns of the Oasis Relax NG TC about XVIF was that this could lead to write schemas which wouldn't be valid per the Relax NG specification.

This specifications says that any element and attribute from a "foreign" namespace is removed during the phase of simplification of the schema.

This means that our schema:

 <?xml version="1.0" encoding="utf-8"?>
 <element xmlns="httphttp://relaxng.org/ns/structure/1.0"
  xmlns:if="httphttp://namespaces.xmlschemata.org/xvif/iframe" name="foo">
  <if:pipe>
   <if:transform type="http://namespaces.xmlschemata.org/xvif/regexp" 
                    apply="split/,/"/>
   <if:validate type="http://relaxng.org/ns/structure/1.0">
     <if:apply>
      <oneOrMore>
       <choice>
        <value>foo</value>
        <value>bar</value>
       </choice>
      </oneOrMore>
     </if:apply>
   </if:validate>
  </if:pipe>
 </element>

is read by a non XVIF Relax NG processor as:

 <?xml version="1.0" encoding="utf-8"?>
 <element xmlns="httphttp://relaxng.org/ns/structure/1.0"
  name="foo">
 </element>

Which is not valid. The fall back mechanism which I have implemented consists to adding an alternative for non XVIF processors which will be ignored by XVIF processors, for instance:

 <?xml version="1.0" encoding="utf-8"?>
 <element xmlns="httphttp://relaxng.org/ns/structure/1.0"
  xmlns:if="httphttp://namespaces.xmlschemata.org/xvif/iframe" name="foo">
  <if:pipe>
   <if:transform type="httphttp://namespaces.xmlschemata.org/xvif/regexp" 
                    apply="split/,/"/>
   <if:validate type="httphttp://relaxng.org/ns/structure/1.0">
     <if:apply>
      <oneOrMore>
       <choice>
        <value>foo</value>
        <value>bar</value>
       </choice>
      </oneOrMore>
     </if:apply>
   </if:validate>
  </if:pipe>
  <text if:ignore="1"/>
 </element>

Note the if:ignore attribute which will be ignored (as a foreign attribute) by non XVIF processors and will instruct XVIF processors to ignore the pattern.

Authors who want to write portable schemas are invited to provide this kind of alternatives to their if:pipe(s) for non XVIF processors.

An interoperability framework can't be an isolated technology and XVIF is linked to many other developments. These links to other technologies include:

Finally, I am considering adding some features to XVIF: