You are here: Home > What's New > Accelerating Adoption of XML Vocabularies

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:

  1. When you create your XML vocabulary, specify not only the meaning of the markup but also its behavior in applications that process it.
  2. Specify conformance rules.
  3. Create a test suite.
  4. Create an application that implements the behavior.
  5. Validate the application against the test suite.
  6. 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:

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).

Data Interoperability

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.

Recap

Here are the main points:

  1. 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.
  2. 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.
  3. 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.

Translation

Elana Pavlet translated this article to Hungarian: Hungarian translation

Marek Murawski translated this article to Polish: Polish translation

Ashna Bhatt translated this article to Thai: Thai translation

David Diaz translated this article to Ukranian: Ukranian translation

Maximilian Neumann translated this article to German: German translation

Zoltan Solak translated this article to Turkish: Turkish translation

Elsa Jansson translated this article to Finnish: Finnish translation

David Mucchiano has translated this article to Swedish: Swedish translation

Laura Beoschat has translated this article to French: French translation

Lars Olden has translated this article to Norwegian: Norwegian translation

Alana Kerimova has translated this article to Estonian: Estonian translation

Martin Aus has translated this article to Kazakh: Kazakh translation

Milica Novak has translated this article to Croatian: Croation translation

Sandi Wolfe has translated this article to Russian: Russian translation

Sherali Niyazova has translated this article to Uzbek: http://eduworksdb.com/accelerating-adoption-of-xml-vocabularies/

Artur Weber has translated this article to Portuguese: Translation into Portuguese for https://www.homeyou.com/~edu/

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: March 11, 2021