Accelerating Adoption of XML Vocabularies
Want to accelerate the adoption of your XML vocabulary? One way is to have an 800 pound gorilla force everyone to use it. But that will soon result in resentment and rebellion. A better way is to create something that people will really want to use and doesn't require of them a large investment in time or money and lets them start interoperating immediately. Here's how:
- When you create your XML vocabulary, specify not only the meaning of the markup but also its behavior in applications that process it.
- Specify conformance rules.
- Create a test suite.
- Create an application that implements the behavior.
- Validate the application against the test suite.
- Make the application available to the world.
Ideally, several implementations of the application will be created (each with the same behavior, of course!). That way users can select an implementation based on its performance or size or which programming language it was implemented in.
That's it! Do this and your XML vocabulary can be quickly adopted.
Example: Consider the XSLT vocabulary. The XSLT specification specifies not only the meaning of each element and attribute but also their behavior. The XSLT specification contains conformance rules. There is an XSLT test suite. An application—called an XSLT processor—has been created which implements the behavior specified in the XSLT specification. In fact, multiple implementations of the application have been created: Xalan, Saxon, Sableton, and others.
Let me elaborate a bit more on what I mean by "specifying behavior." Consider again XSLT. The XSLT specification says that the <xsl:for-each> element identifies a collection of nodes. That is meaning. It also says that a compliant application must iterate over each node identified by the select attribute (the for-each element has a select attribute) and execute the elements within <xsl:for-each>. That is behavior. Thus, the XSLT specification specifies how an application must behave on the <xsl:for-each> element. Ditto for the entire XSLT vocabulary.
The XML Schema specification does a good job of specifying the behavior of XML Schema validators. For example, it specifies that, for an element declaration in an XML Schema, a validator must check that the XML instance document contains the correct number of occurrences of an element and its content is of the correct type. Thus, it specifies how the validator must behave on the XML Schema vocabulary. So, to "specify behavior" means to describe "for this element (or attribute) in the vocabulary, the application must do this, this, and this."
The mistake people make when creating an XML vocabulary is that they fail to specify its behavior. They leave it up to "the world" to figure out what the behavior should be. A classic example of this is HTML. Browser developers had to decide what the behavior should be. They had widely varying ideas about the proper behavior. The consequence was that IE, Firefox, and the other browsers all behaved differently. It took 10 years before they finally converged on a common understanding of the behavior. Had the HTML specification stated the behavior, provided conformance rules and a test suite, then we would have had identically behaving browsers 10 years ago.
One thing you must consider when specifying behavior is this: will your XML vocabulary be fed into the application as one XML document or as two XML documents? (Or more?) Let's take some examples to see what I mean:
- Browser applications process one document (an HTML document)
- XML Schema validators process two documents (an XML Schema document and an XML document)
- XSLT processors process two documents (an XSLT document and an XML document)
In these examples the applications are: browser, XML Schema validator, and XSLT processor. These applications process an XML vocabulary. Depending on the XML vocabulary, an application may require one input document or two input documents (or more).
I have often heard it said, "To achieve data interoperability each application must interpret/understand the XML vocabulary in the same way."
What better way to ensure the same interpretation/understanding than to use the same application!
By using the same application we can have perfect data interoperability. NOTE: When I say "the same application" I mean a set of implementations. Thus, Xalan, Saxon, and Sabletron are all the same application—they are all XSLT processors. Using the same application doesn't mean, for instance, that everyone uses Xalan. One person may use Xalan, another uses Saxon, and another Sabletron. That's okay; they all have the same behavior; they all follow the XSLT conformance rules; they all pass the XSLT test suite.
Here's an example to illustrate how data interoperability is achieved through shared usage of the same application.
Example: Consider XSLT. I can create an XSLT document and run it on my XSLT processor. I can send the XSLT document to you and you run it on your XSLT processor. We get the same behavior. We agree perfectly on what the <xsl:for-each> element means and how it should behave. Ditto for all the other elements and attributes in the XSLT vocabulary. We have successfully interoperated. What enabled this? Answer: What enabled the interoperability is the fact that we are using the same application. (Again, I must stress that it doesn't mean that we are using the same implementation of the application; you may be using Xalan and I may be using Saxon; that's okay; they are both XSLT processors.)
I can create a second XSLT document and send it to you. Again, we have perfect interoperability. And a third XSLT document. And so forth. The XSLT processor application facilitates endless different XSLT transforms be created, exchanged and executed with perfect understanding/interoperability.
Here are the main points:
- When you create an XML vocabulary, specify the behavior of the XML vocabulary. Specify conformance requirements. Create a test suite. Implement conforming applications, each with the same behavior (the implementations may vary in size, performance, programming language, etc). Everyone use the implementations.
- Data interoperability is not achieved through shared understanding of the XML vocabulary. Data interoperability is achieved through shared usage of the XML vocabulary's application.
- Creating an XML vocabulary without specifying its behavior is a bad idea. It is a recipe for delayed data interoperability at best, failed data interoperability at worst.
Petra Vlasic has translated this article to Macedonian: http://makescience.net/accelerating-adoption-of-xml-vocabularies/
Petra Vlasic has translated this article to Bosnian: http://petravlasic.net/accelerating-adoption-of-xml-vocabularies/
Last Updated: November 22, 2015