XSD Schema is Not the Only Way

More than any other W3C Recommendation is the XSD the most criticized one. There are many reasons for the criticism but let's have a look at the most painful one, the readability.

I want to read XML description

There is a widely used technology for description of XML data structure called XSD Schema. You write an XSD for your XML data and then send it to the other sides of the planned data exchange in order to keep the XML structure. When the person on the other side receives the Schema, he needs to understand the data structure and prepare an API. He actually needs to read something like this:

<xs:element name="Books">
 <xs:complexType>
    <xs:sequence>
      <xs:element name="Book" maxOccurs="unbounded">
        <xs:complexType>
          <xs:attribute name="title" type="xs:string" use="required"/>
          <xs:attribute name="author" type="xs:string" use="required"/>
          <xs:attribute name="pagecount" type="xs:integer" use="optional"/>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>
</xs:element>

For a computer it's not a problem to read XSD but it is a little exhausting for a human being. So first you will just use a "sketch", example data with commented data types.

<Books>

  <Book title="required string" author="required string" pagecount="optional int"/>
</Books>

This way it is convenient enough for us to explain what the XML data should look like, but a parser needs real schema language for the validation, so we have to maintain several descriptions and keep them synchronized. We can see this happen in this and many other use-cases. But there are several other schema languages available. Let's have a look at the XDefinition, which is the closest one to your first "sketch".

XDefinition

XDefinition is a schema language developed from the beginning with close respect to the natural readability by keeping the form of the XML data source. Designed to be understandable not only for programmers but also to analysts, system architects and all the other parties concerned in the project. This kind of approach leaves no space to misinterpret data description during their exchange, starting from the architects to database specialists. So take a look at the complete XDefinition of our XML example.

<xd:def xmlns:xd      =  "http://www.syntea.cz/xdef/2.0"
         xd:name      =  "Books"
         xd:root      =  "Books">
  <Books>
    <Book title="required string" author="required string" pagecount="optional int"
        xd:script="occurs *"/>
  </Books>
</xd:def>

Implementations of the XDefinition processor are available in the Java 1.3-1.6 and .NET. The first thing on your mind probably is that it can't fully substitute the XSD functionality ... but it can, and much more than just substitute it.

Not just validation

Capabilities of the XDefinition exceed the boundaries of the validation concept. There is the possibility to make a transformation of the document based on the values of the input document or the other inputs, for example a database accessed by external methods. External methods are the methods of classes accessible through a context classloader available to the XDefinition processor. That means that you can run your own code from the XDefintion and use the result when processing the XML document.

Support

There is an available plugin to the NetBeans IDE providing a wide support for XDefintion, plugin for validation of XML in the oXygen XML editor, plugins for Eclipse and IntelliJ IDEA IDE's are in the early stage of the development. The NetBeans plugin comes with the context help, an example project, it's own XDefinition data type, an ability to check XDefinition, track bugs and an ability to validate XML documents.

Don't be afraid to try something else

There is a lot more to find interesting about the XDefinition, look for them on the web of Syntea software group a.s. or on the XDefintion page.
Resources:

Tutorial with examples

XDefinition guidepost