XML is everywhere these days. It is used for passing data around, for specifying metadata and even as a programming language for tools such as Ant and Jetty.

When XML is generated by various development and run-time tools (e.g., for serializing Java objects into SOAP), its complexity and readability don’t matter much since humans have to deal with raw XML only occasionally (e.g., to troubleshoot a problem).

However, more often than not, XML is written directly by developers mostly with the help of a validating XML editor/IDE (that is, if developers are lucky and Schema/DTD are available). WSDL (in the case of WSDL-to-Java approach), XML schema and Ant build files are a just a few examples when this is the case.

Using XML as a mark-up language for otherwise mostly text documents (e.g., XHTML) it’s not a totally bad idea. However, XML is ill-suited for specifying complex metadata which dynamic dependencies or for wiring command-based logic (e.g., Ant) or for defining domain-specific languages. That is, ill-suited for humans.

For starters, XML is unlike any other programming language (or a natural language). Consider a basic XML construct: <name>value</name>. In any other language it would’ve been written as “name=value” (or “name:=value”, or something similar). An assignment is a construct familiar to most of us from math, even though we may not understand the intricacies of r-value versus l-value. It is intuitive. XML relegates this basic construct to attributes that can only be used as part of an element. Using attributes, a simple assignment can be expressed as <name value=”my value” />, which is a bit easier to understand than a purely element-based construct. However, “value” attribute still seems kind of redundant.

Another annoying feature of XML is closing tags. Closing tags is what makes XML verbose. (What’s interesting, SGML, which XML is derived from, did not require closing tags, so one could write something like <TAG/this/.) In most programming languages we express grouping and nesting using brackets or parenthesis or braces. This is true for function arguments, arrays, lists, maps/dictionaries, tuples, you name it, in any modern programming language. XML creators for some reason decided that repeating the name of a variable (tag) is the way to go. This is a great choice for XML parsers but a poor alternative when XML is written/read by humans.

Closing tags do help when the nesting level runs deep. But it does hurt in cases when there is a need to express a simple construct with just a few (or one!) data items. Problem is, our brain can only process limited number of items at a time, so intermixing data that needs to be processed with tags that serve as delimiters for this data makes comprehension more difficult. For simple lists, a comma-delimited format could be a better choice in many situations.

In general, repeating the same set of tags over and over again to define repetitive groups makes XML difficult to read, especially when each element contains just text:

    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
        <welcome-file>index.htm</welcome-file>
        <welcome-file>index.jsp</welcome-file>
    </welcome-file-list>

Compare this with a simple property/comma delimited format:


welcome-file-list= index.html, index.htm, index.jsp


Finally, what's up with angle brackets? I suppose, brackets could be justified when an element has multiple attributes. In many cases, however, elements don't have attributes and so an angle bracket is simply a way to distinguish a tag name from data. This is again, counter-intuitive and different from many modern programming language. Normally, variable names are not bracketed or quoted, instead, values are. Also, if there was a need to use a special symbol for denoting variables, wouldn't using "$" or "${}" be a more intuitive option for most of us?

Of course, XML has many advantages, the key one being that it is very easy to develop grammars for XML documents (using DTD or Schema). Another one is the fact that grammars are extensible via namespaces. Finally, any XML grammar can be parsed by any XML parser; to a parser an XML document is just a hierarchy of elements.

This simplicity, however, comes at great price. Expressiveness of XML is extremely limited. It only has a limited number of constructs and no operators. While it's adequate for its role as a markup language for text files, it puts a lot of constraints on any more-or-less complex metadata format, let alone something requiring procedural logic, such as Ant or XSLT. As a result, intuitiveness of XML-based grammars suffers.

I'm not saying that we must stop using XML altogether. It has its place. But we should not be applying it blindly just because it's the only widely available tool for creating domain-specific languages. For starters, BNF/EBNF, should be part of any developer's arsenal (along with ANTLR). And good old name/value pair and comma-delimited formats should be seriously considered for simple situations that do not require support for hierarchical structures.

Over the last several weeks I‘ve been working on developing XML schemas for a
client to support information exchanges between several different organizations,
so it was important to make the schemas very explicit and “tight“ so that each
party can validate XML before or after sending it. The XML documents could be
used in conjunction with Web services or as part of “old-fashion“ file based
exchange. In short, this was pretty typical system integration task.

The client had already decided to standardize on XML Schema, so using Relax NG
or Schematron was not an option.

XML Schema provides a lot of different capabilities but based on my experience I
think that it could benefit from some improvements. Here are my random thoughts
on this. Now, I don‘t claim to be the ultimate XML Schema expert, so take it for
what it‘s worth.

• Schema‘s verbosity and unwieldy syntax makes it a poor candidate for
  communicating and publishing XML structure and rules to the wide audience of
  technical people from different organizations that may or may not know XML
  Schema. For example, “minOccur=0“ means “optional field” which is probably not
  very intuitive to anyone unfamiliar with the Schema specification. Even after
  formatting the schema for publishing (e.g., by using xsddoc)
  schemas are still hard to understand. Of course, one can use the annotations and
  try to explain each type in plain English, but then the documentation always
  tends to get out of synch.

  The obvious counter-argument here is that XML Schema is designed to be the data
  modeling/validation tool and as such it is not suitable for capturing business
  requirements but I just think that it would be nice if it could really be used
  for both, essentially becoming the “system of records“ for integrating different
  systems and organization.

• Error messages thrown by XML parsers are far from being the most intuitive (this
  obviously depends on the parser and I have not done any comparative analysis).
  For example, missing required element results in “Element ‘element name‘ is not
  valid for content model“ where ‘element name‘ is the name of the element
  following the missing required missing element. Why can‘t the parser simply say
  “Required element is missing“? Again, this problem is exacerbated when you‘re
  dealing with people with only cursory XML Schema knowledge. I‘m not aware of a
  standard way to customize error messages, so in my case developers will have to
  do error translation in the code.
• XML Schema users are forced to use regular expressions for defining any more or
  less complex template for simple types (phone number, SSN , etc). This poses a
  problem in an environment where you can‘t expect all users to be familiar with
  regexp syntax. When you get a message “Value does not match regular expression
  facet ‘\+?[0–9\-\(\)\s]{1,25}“, it could very easily befuddle an uninitiated. I
  wish there was a simplified templating mechanism, may be something similar to
  java.text.MessageFormat “##.##“.
• Reuse capabilities in XML Schema are not perfect. “extend“ only allows to append
  an element to the end of the sequence. “Restrict“ requires repeating the content
  model of the parent type. This creates very brittle schemas and violates DRY
  principle. There is no way to parameterize an XML type. Let‘s say there is “name“
  type with “first“ and “last“ elements. When a new person is added, I want “last“
  element to be mandatory. In “update“ situation all fields could be optional. I
  wish I could make “minOccur“ a parameter here.
• XML Schema may seem very OO-like at the first glance, but in fact it is missing
  some important OO-like capabilities. For instance, there is no element-level
  polymorphism. In the example above, I wanted to change the “behavior“ of “last”
  (some aspect of this type definition) in a subtype and I can‘t do that.
  Inheritance by restriction for complex types (I don‘t have a problem with using
  it for simple types) is IMO counter-intuitive. So now I can have a child which
  does not have all properties of its parent, and so there is no way to enforce
  optional elements for all children.
• Element and type scoping could‘ve been more flexible. All declarations are
  either parent element-scoped (local) or global. This does not allow me to define
  a reusable type or a group scoped to certain parent element or to a file (any
  more or less complex schema would have to broken down into multiple files for
  manageability sake). So say I have a name type for person‘s name (first, middle,
  last) and business‘ name type with a different structure. If I want use to
  person‘s name type for different elements within Person type, I will have to
  define as global and name it PersonNameType, essentially embedding parent‘s name
  into the child‘s name. I wish I could simply define NameType and specify what
  parent type or element it is scoped to.
• XML Schema is a declarative language and so it lacks programming constructs,
  which is fine. But there is still a need for Schematron-like facility or the
  scripting language for expressing complex rules (such as cross-field validation).
  Schematron works fine when embedded inside annotations, but it requires a
  separate validation step and Schematron XSLT . So it would be great if this
  capability was supported by the Schema standard and natively understood by XML
  parsers. This would make schemas truly self-contained.

So my wish list is actually quite simple:

• Make XML schemas easier to understand for non-technical users or people without
  schema knowledge perhaps via some intelligent translation mechanism.
• Make the Schema more powerful by allowing programming constructs, variables and
  more flexible scoping.

Tags: XML, Schema