DSDL Interoperability Framework
by Eric van der Vlist
|
Pages: 1, 2, 3
3.2.3. XVIF features
The most basic building block of XVIF is "if:transform", which defines 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 -->
Note that the implementation of T may be held in an "apply" element or attribute, and it may be located in an external resource (if:apply/@href).
A validation is simply 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 identifying 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 indentifying 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
here -->
<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 there is to it.
3.2.4. Why micro-pipes
The examples shown so far were simple and do not demonstrate any differences from the Schemachine approach. There are a couple of reasons where micro-pipes are used.
-
Modularity: these pipes can be used in named patterns and reused in lieu of native Relax NG patterns:
<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>
-
Micro-pipes play nicely with the schema language. If we want to validate the list as a comma-separated list if a type attribute is "csv", and as a whitespace-separated list if the type attribute is "list", we can write
<?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 it is important to ensure 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.
3.2.5. Perspectives
An interoperability framework can't be an isolated technology, and XVIF is linked to many other developments. These links to other technologies include:
-
W3C XML Schema: I see no reason why XVIF couldn't be associated with W3C XML Schema as it is with Relax NG.
-
Schema annotation: we have seen how closely related transformation and validation are: validations could be extended to add annotations to instance documents.
-
XPath 2.0/XPath NG axis: these annotations could be used by the proposal from Jeni Tennison to add extension axis to XPath 2.0 and/or an eventual "XPath NG".
-
Schemachine: some features of Schemachine could be added to XVIF or, XVIF could be used within the Schemachine framework, or a standalone version could be developed.
-
XSLT: XVIF could be used as a XSLT extension element.
Finally, I am considering adding some features to XVIF:
-
If/then/else statements.
-
Sub pipes.
-
Variables.
