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 nodeset "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 nodeset here -->

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

 <!-- The context nodeset (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 nodeset is left unchanged -->

Transformations and validations can be chained in pipes:

 <if:pipe>
  <!-- The context nodeset (x) is defined by the host language here -->
  <if:transform type="URI indentifying the nature of T2">
    <if:apply>
       Implementation of T2
    </if:apply>
  </if:transform>
  <!-- The result T2(x) is the context nodeset 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 nodeset 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!

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!

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: