The Real Cost of XML Tags

Oscar Wilde infamously quipped that a cynic is someone who knows the
cost of everything but the value of nothing. If this is true (and if I
have my inference logic the right way round), then it can be concluded
that all schema writers are idealists. They seem to know the value of
everything (how to tag it) and the cost of nothing (money consumed by
tags).

Do you sense a short fuse burning? A sense that the writer is not at
peace with the universe in general and XML schema writers in
particular? You are darned right my fuse is burning. For weeks now, I
have been cutting code to do some XML data processing that would have
been much easier if only the schema creator had shown some
understanding of the true cost of XML tagging.

"Ah", I hear you say, "You are being selfish again. You want all the
XML to be perfect for your specific needs. Typical becubicled,
besandled, bearded, belligerent, bellicose, back-end system development
type."

Well, yes, of course I would like my life made as easy as possible, but
hear this: Where do you think all the money goes on XML markup? In the
Total Cost of Ownership calculations to do with XML tags, where are the
real costs?

Did you say, "Data modeling/schema creation"?

Bzzzzzt. Thank you for playing, but that is not the correct answer.

The bulk of the costs are attributable to each and every lowly XML tag
accumulated in data processing. Every time a developer writes an XPath
expression, a SAX handler, or weaves a DOM NodeList, he or she is
contributing to the XML tags' cost of ownership. Every time a developer
backs off from cutting code because of the sheer complexity of the XML
structure being manipulated, you are accumulating costs.

Where does the complexity come from? How complicated can processing a
few cuddly little tags peppered with some good old PCDATA be?

Complexity Comes from the Schemas
A schema (be it DTD, XSD, or RNG) makes saying, "At this point, A or B
or C or D can occur zero or more times", very easy. Sounds harmless,
but look at it from a programmer's perspective. At this point in the
document structure, elements A to D can occur any number of times in
any order. Lets keep things simple by restricting the elements to
having two values. That means that my "business logic" has to deal with
8 main branches at this point in the structure. Now add in another
element E with the same two possible values. The main branches in my
business logic now number 16.

Simply put, my software's so-called "state space" grows exponentially
with the number of things that can occur at a given point in a document
structure. The number of possible occurrences at any given point in the
structure is directly related to the schema.

Anything that grows exponentially is bad news for software development
(except of course caffeine levels). Introducing non-terminals into the
schema can significantly reduce state space explosion.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine