[6 May 2009]
Short version: I’ve made a new toy for playing with one aspect of XSD 1.1, namely the conditional inclusion of elements in schema documents, controlled by attributes in the vc (version control) namespace. The experience has reminded me of reasons to like the vc:* design and of reasons to like (and hate) Javascript in the browser.
Now, once more, from the top.
There has been some discussion on xmlschema-dev lately about the attributes in the version-control (vc) namespace defined by XSD 1.1 Part 1: Structures (specifically, in section 4.2.1 Conditional Inclusion.
It’s a relatively simple mechanism. If you write in your schema document
<xs:element name="E" vc:minVersion="1.1"> <!--* declaration for use with 1.1 processors *--> ... </xs:element>
then the declaration will be used by any processor for XSD 1.1, or for any version of XSD with a version number greater than 1.1. If on the other hand you write
<xs:element name="E" vc:maxVersion="1.1"> <!--* declaration for use with pre-1.1 processors *--> ... </xs:element>
then 1.1 becomes an exclusive maximum value for the version number: processors for versions with version-numbers less than 1.1 should use this declaration, and 1.1 and later processors should ignore it. Similar mechanisms are available for checking to see whether a given datatype or facet is automatically available as a built-in or not.
The most immediate and obvious benefit of the mechanism is to make it possible for XSD 1.1 processors to survive usefully in some future world where they may be confronted with schema documents from a later version of XSD. Or rather, to be more precise: the vc mechanism makes it possible for schema authors to write schema documents for (say) XSD 3.2 processors which will fall back to some graceful alternative when used by an XSD 1.1 processor. Or, if that is really not desirable, the mechanism makes it possible to make the 1.1 processor reject the schema document (just use some construct not legal in 1.1), so you can require a certain minimum level in the processors used for your schema document.
Other specs I know of (XSLT 1.0 and 2.0, SVG Tiny, …) have similar mechanisms; I am glad that the XML Schema working group took the time to look at them and try to learn from them. In specifying the vc mechanism we tried to keep the mechanism simple (although the temptation to add features can be very strong) and to provide control for the schema author, who needs to be able to specify what fallback to use in different situations, including the rule “give up, stop now, do not try to process this schema document”. A blanket rule saying a 1.1 processor should just ignore anything it doesn’t understand — which some people repeatedly urged us to adopt — lacks the requisite property. It does not allow the user (here the schema author) to say, in effect, “Look, if you don’t support feature XYZ, there really is no point in trying to use this schema document.”
XSD 1.0 processors don’t support the mechanism out of the box, of course, since it wasn’t specified as part of XSD 1.0. But the vc mechanism is designed to be compatible with 1.0, in the sense that an XSD 1.0 processor can be retrofitted with it, without ceasing to be 1.0-conformant. It is to be hoped that 1.0 processors which are now being actively maintained do add support for the vc mechanism: it’s simple, and it will help the 1.0 processor remain relevant in a world with both 1.0 and 1.1 schema documents.
Schema users can exploit vc even if the processor they use does not have vc support built in. It’s not hard to write an XML transform (as an XSLT stylesheet or using any other mechanism you like) to implement the vc mechanism, and run it over schema documents before presenting them to your processor. You can even build the functionality into a URI resolver and have it handled automatically. (Assuming that your processor or operating environment allows you to supply a customized URI resolver.)
To illustrate the point, and to help people grok the mechanism better, I spent some time recently writing an XSLT stylesheet to perform vc-based conditional inclusion; it’s available from the Black Mesa Technologies web site at <http://www.blackmesatech.com/2009/04/xsd.vc.xsl>. Download it and experiment with it if you wish.
If you’re not sure you want to bother downloading it, you may find it easier to experiment with the vc stylesheet by going to the VC-Filter web page, which provides an interactive interface to the stylesheet, using the XSLT 1.0 processor built into the browser. There’s a text widget into which you can type, or paste, a schema document, some input fields to specify options (what is the XSD version number of the target processor? what additional datatypes and facets does it support?), and a field where the results appear.
In putting the VC-Filter page together, I found the Sarissa library and want to put in a good word for it hee. It really does a pretty creditable job of providing a browser-neutral interface for dealing with XML documents. I don’t know whether it’s perfect, but it’s almost certainly better than I would have done on my own. A word to the wise!