June 27, 2002, 12:00 AM — 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 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 by 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 are an example. In the OO world, the use of archetypes in UML is similar in scope.
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, 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.
