Come Back Database View Technology; All is Forgiven

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:

foo
Hello World

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

» posted by ITworld staff

ITworld

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

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