- From: "Simon St.Laurent" <simonstl@s...>
- To: Hans-Juergen Rennau <hrennau@y...>,"xml-dev@l..." <xml-dev@l...>
- Date: Fri, 18 Feb 2022 09:00:16 -0500
On 2/17/2022 9:58 AM, Hans-Juergen
Rennau wrote:
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|