I have an idea for an interesting online competition. I'd like to call it:

"The Most Gratuitous Use of XML in a serious Web Application."

I can think of a few potential winners. I'm sure you can too.

A good place to look is for XML file formats that consist of a single XML element housing what is called a CDATA section. A CDATA section is XML's equivalent of super strong duct tape, capable of masking a myriad of bletcherous[1] hacks.

Another good candidate is APIs in which every string, every integer and every date have been laboriously and pointlessly exposed as separate Web Services. Way to go Moore's Law[2] - without you we are doomed!

Perhaps my all-time favorite in this category is XML empty element sprinkling. You take a model that looks, say, like this:

{\foo Hello World }

and infuse it with the XML elixir so that it becomes:

<UtterlyXML>
<GroupStart/> <CodeIndicator/>foo <Text>Hello World</Text> <GroupEnd/> </UtterlyXML>

Note that I'm not saying that this sort of thing is necessarily bad; however, it is not necessarily a good way to go about it. It also runs the risk of being sold to the boss as a great leap forward rather than the trivial syntax shimmy sideways, which is closer to the truth.

On reflection, maybe this competition is too easy. How about this for a more challenging question:

"The most powerful idea ignored in the headlong rush to XML based data modeling."

Yes, that is better! A more challenging question to be sure. I have a few candidates in mind. However, pushed as I am to nominate one, I would like to suggest that the well-established database technology of creating data "views" for editing, querying, and viewing is the most powerful idea ignored in the headlong rush to XML-based modeling.

In a traditional database, you start by modeling your data without regard to how it will look in a report, in a data entry screen, in a query. You break your data down into atomic pieces of particular types - strings, integers, dates and so on. You stitch a collection of these together into a record structure and lo! One physical database is born.

Now although you can - and for simple applications probably will - edit data directly into this record structure. However, for any non-trivial application you will take the opportunity to create what are known as database "views". In these views, you set up data entry/data browsing the way you want it. There need be no correlation between the ordering/presentation of data in the view with the physical ordering of data in the database.

Why am I spelling all this out? This is all drop-dead obvious stuff right? The reason I'm spelling it out is that somewhere along the way we seem to have lost this simple and powerful trick in the XML world.

In XML, schemata for data modeling and schemata for data entry/browsing are typically one and the same. Put another way, the XML world does not distinguish physical schemas from logical schemas. When configuring XML editing systems, we feed the one and only schema - the physical model - into the editing tool to create a customized editor/viewer/reporter.

In database land, you are much more likely to create a virtual view of the data first and feed that to the system to create a custom editor/viewer/reporter.

The database view approach seems extremely powerful and sensible. Yet it does not feature a paradigm in the XML world. Odd. Don't you think?

NOTES

[1] http://www.tuxedo.org/~esr/jargon/html/entry/bletcherous.html [2] http://www.webopedia.com/TERM/M/Moores_Law.html