Simon, in many cases misunderstanding comes from attaching to one and the same word very different meanings.
This is an outright conflict, not a misunderstanding.
What you think of saying "XML" is certainly very different from what occurs to me. Could you say in a couple of sentences what "XML" means to you? As to myself, I will, in a moment.
XML is a syntax that lets us create named structures in text
documents. That is all it can ever be. Markup is a slightly
broader practice offering more variations in the syntax.
Layers beyond that offer tools for processing XML. (If only they
were neatly layered, but that's another problem.)
Did you hear Leonard Bernstein lecture on Beethoven's fifth symphony, explaining how large parts of the symphony are an unfolding of the first four notes - ta ta ta taaa? Beyond the musical layer, it is a lesson on what understanding means, or may mean: relate the multitude of external form to a quintessence taking hardly any space at all.To me, XML has much in common with a symphony, as so amazingly much is unfolded from so little.
Bluntly, no. Even the conflicts within the wildest symphonies
are far more coherent than the levels of chaos within any large
group of XML (or really any) documents. Instead of a glorious
unfolding, imagine thousands of different symphonies playing at
once, with stupendous showings from beginner recorder, trumpet,
and violin players, as well as layer after layer of musical forms
that use different structures than western classical formulas.
There is no maestro.
In that metaphor, XML gives us ways to describe sounds, perhaps
fundamental descriptions of waves. However, combining everything
you can do with sound into one conversation is a terrible fate
that mostly will make you want to turn down the volume or shut it
off entirely. (Which is basically what the world has done to
markup.)
Of course, saying XML I mean XML technology, of which XML syntax and even any concrete XML documents and even their purpose and intent (realistic or not) are but a marginal aspect. So one way to look at it (there are certainly quite a few interesting ones) is acknowledge these four notes: XDM & XPath. XDM gives a formal answer to the question - what is information? And XPath outlines a coherent answer to - what can you do with information, what can come out of information + information? And just stop for a moment and think of the beauty of the XDM: What is information? It is a value. A value is a sequence of items. An item is a node (binding information to a point in space), or an atom, or a mapping of a value to values (map, array, function item). Now, if this is not beautiful, visionary, fraught with the potential of unfolding, what is? What is "smaller and more useful"? (I mean, in the field of information technology.) Theoretical as this may sound, to me it is practice, more than anything: amazement at the sheer mechanical power of XPath, accelerating the mass of information (if I may say so) has been my daily experience for 20 years. And isn't it worth second thoughts how the XDM enables an integrated view at so much structured information (HTML, JSON, XML, CSV), their content not only conceptually, but logically fused into a single forest (with the XDM you can, without, not!) which you may inhabit with the ease and agility of a merry squirrel? But wait, non-spatial relationship between items of information (relationship non based on tree axes) is not treated explicitly, is this a weakness? Could or should the XDM be extended so as to embrace relationships explicitly, perhaps allowing RDF triples as a new item kind, and perhaps a new kind of node property (along with parent, child and attributes)? Or better not do that, keeping things simple, and emulate this enrichment? I don't know, I am wondering, do you wonder, too?
To continue the metaphor, we keep building tools that might be
great for Beethoven symphonies, but forget that most of the world
is not (and should not be) Beethoven. We can create similarly
euphoric descriptions of, say, the intricacies of Western tonal
harmony and all of the exceptions that Beethoven and friends use.
Unfortunately, in so doing, we reliably create cultures that look
down upon simpler approaches, and insist that they must conform
somehow to our particular set of choices. The folds are not
necessarily where we insist they should be. This is not
enrichment.
Your vision of universal data approaches is unattainable and actively harmful. Similar visions during the dot-com boom brought investments and insistence that XML must conform to various and incompatible dreams of uniquely identified triples and strongly-typed programming data structures. (Layer cake models.... sigh.) Unfortunately those threads continue, though programmers and users broadly have more and more often thrown them off or set them on fire in their perpetual quests for things that work in their specific contexts.
I think that you do not, because for you, the XDM is not interesting, and XML is something very different. Otherwise I would not understand your tone of a resigned looking back at what is over and for some people a bad memory, although I should think we have hardly scratched the surface, hardly begun the unfolding. Summarizing XML in such an offhand and vague way, as the many things which did not change the world. To someone who regards XML as something akin to a science of itemized information it would not occur to chime in.
XML - markup generally - does not resemble a "science of itemized
information". We all try at various times to control and
constrain markup to meet specific needs, but there is no grand
underlying scheme, no Pythagorean XPath harmonies that hold it all
together.
(Even in symphonies - especially in symphonies - we already cheat the Pythagorean system with equal temperaments so we can move around more easily.)
Often, surfaces are worth keeping, in no need of further
scratching. Tools that help us work with different kinds of
markup are great, but pursuing unity where there is no reason to
expect underlying unity creates an enormous mess.
What I would really like you to see in my post is not an attempt to argue, far from that, but a gentle reminder that there are different things which one might see in XML, and the whole logic of your point of view does not apply at all to mine, and vice versa. A good day to you - Hans-Jürgen
I am not sure if such visions can cause more damage than they
already have, but I can no longer imagine good reasons to pursue
that logic.
Thanks,
Simon
Over the past few decades, I've seen wave after wave of people who think that the tools we have created here are a virtuous version of the One Ring, a single tool that will help humankind catalog and communicate everything in a neat and logical way, eventually binding them together to form a more coherent future.
Markup messianism might have made sense in the early days of XML, when it seemed like we had something genuinely new here, or at least something old on the edge of making a massive breakthrough. Labeled structured exchangeable data is awesome stuff! I was also way too enthusiastic in those early days.
Unfortunately, we keep tripping over our dreams. We just needed one more layer to make markup universal, whether it's graph structures, namespaces, a schema language, an enhanced transformation language, a new data store, modeling tools, adoption as a default format by popular enterprise (and consumer) software, or the world waking up to the magic we have to offer...
We've been through all that. The original cleanup process that extracted XML from the many possibilities of the SGML Handbook has been drowned in a blizzard of technologies many many times larger. Even as developers and consumers and managers wandered away, we kept offering more. The tangles only grow tighter and more specialized, though occasionally lucrative. For much of the world, XML and its related technologies are a lingering bad memory.
There are good things among our many piles, but there are no universal solutions here. We have convenient syntax and tools for consuming and transforming it. We can suggest best practices for applying it to various kinds of information. We have bridges to a lot of other technologies, though many of those bridges were always partial and are lately decaying.
I hope that someday the SGML-to-XML cycle will begin again, that we'll sort through the piles we've hoarded with a different eye to produce something smaller and more useful. Getting to that, though, likely means that we have to want to do less, not more.
Thanks,
Simon St.Laurent
Markup minimalist
Real-life hoarder