CTO Articles

Home > News > CTO Articles

IT World
XML IN PRACTICE --- June 27th 2002

The Opposite of Hierarchy

By Sean Mc Grath

It is not every day that one can search Google for a word and get precisely *one* hit. Today was such a day for me. I needed a word that means the opposite of the word "hierarchy". Some sources say "anarchy" is the word I'm looking for, but it does not suit my purposes as we will see. It sounds too unruly!

Thanks to Google, I came across the word "cholarchy" which had exactly one hit [1] when I tried it. Of course, if you are reading this article on the Web and Google's spider has already visited, then the hit count is no longer one. The Web is a river and you can never step into the same river twice....

The word cholarchy is a great word. It may not even be the right word or a real word (it is not in Webster's and I don't have a subscription to the subscription-only Oxford English Dictionary) but it sure is a useful word.

Cholarchy makes XML people break into a rash. XML people naturally think in terms of hierarchy. Hierarchy is, arguably, the fundamental ethos of XML. Hierarchies are good and by implication cholarchies are bad. Hierarchies are natural. Hierarchies are useful. Oh, and finally, hierarchies are just plain fun!

It seems we humans have a deep need to create hierarchies. XML panders beautifully to that primeval urge. As soon as two or more concepts line up in a row (the simplest possible cholarchy), we hierarchy zealots swoop and classify the concepts into a hierarchy. Just as nature abhors a vacuum, it seems that mankind abhors a cholarchy.

The obvious place where XML wallows in its ability to create hierarchies is in document structures. Everyone goes through the aha! moment when they realize the vista opened up by the ability to put tags inside other tags. Hierarchical hedonism ensues.

Although tagging XML documents facilitate wonderful hierarchy-fests, the same is not true in schema languages. This may sound like an odd assertion given that schema languages exist to allow us to codify our hierarchies. Here is what I mean :

What happens when two or more element type declarations line up in a row? The hierarchy zealots swoop! This is where things get interesting! They get interesting because -- unlike XML tags --there is no generally accepted way to create hierarchies of element type declarations.

Some designers would argue that element types are basically classes in the object oriented programming sense of the word. In this view, the way to add hierarchy to element types is to organize them into class hierarchies with inheritance relationships. The ultimate expression of this view is not to use any XML schema language to capture these hierarchies at all. Rather, the models are managed in some mainstream OO technology (such as UML) and XML schema language notations -- typically W3C XML schema -- are generated from the models. This is the approach used in ebXML and HL-7 for example.

Others would argue that good old DTDs provide a basic facility for this, which can be used to create simple hierarchical relationships between element types known as parameter entities. In many DTDs you will find parameter entities with names like "block", "inline", "heading", "list" and so on. These act as containers and classifiers for elements - a pure XML 1.0 approach to basic object oriented classification. This is the approach used in the XHTML DTD for example.

Others would argue that the way to add hierarchy to schemas is to annotate element types with attributes that specify the classification system - architectural forms[2] are an example. In the OO world, the use of archetypes in UML is similar in scope[3].

As ever, all the approaches have pros and cons. The UML approach works well at the expense of making the only legible version of the model visual (and most likely, proprietary to the tool that created the visualization.). Parameter entity approaches have the advantage of being pure XML 1.0 but are a quite limited, purely lexical approach. In particular, the classification is invisible to all but the most DTD-aware, validating parsers and thus the hierarchy information is not available easily to downstream processing. The architectural form approach has the advantage that the hierarchy information is available downstream. However this approach has not received widespread support in the industry. Some time ago[4], I suggested that XML was just a special case of some more general technology. I am beginning to think that the next level up is now taking shape. We started by using XML to add hierarchies to data. That is now an established and fairly well understood. The next big frontier to be conquered by the hierarchy brigade is the models for the data -- the schemata. In a word, meta-models and meta-modeling.

Just when you thought the level of abstraction was leveling out, we seem to be heading north again!

Hmmm. I wonder what the opposite of "meta" is?...

NOTES

  1. http://itw.itworld.com/GoNow/a14724a60714a114515055a3
  2. http://itw.itworld.com/GoNow/a14724a60714a114515055a8
  3. http://itw.itworld.com/GoNow/a14724a60714a114515055a1
  4. http://itw.itworld.com/GoNow/a14724a60714a114515055a4

 

Sean is co-founder and Chief Technology Officer of Propylon and is an industry–recognised XML expert.