[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Data Model(s) for XML 1.0 / XML Devcon / DOM / XSL / Query
- From: Tim Bray <email@example.com>
- To: firstname.lastname@example.org
- Date: Fri, 23 Feb 2001 21:14:41 -0800
At 11:26 AM 23/02/01 +0000, Sean McGrath wrote:
>In the light of recent debate about the intertwingling
>of XML specs and the PSVI and Henry Thomsons
>excellent keynote at XML Devcon
>isn't it time to accept that not specifying formal
>post-parse data model(s) for XML 1.0 was a big
... and so on. Sean makes some good points, particularly
that a lot of hair on the DOM is due to the requirement
that it support authoring applications.
And Henry's slides are damn convincing... maybe all those
angle brackets really *are* ephemeral fluff, and the
reality is the infoset, or actually, since that doesn't
actually help the ordinary programmer very much, the API
based on the infoset foundations, and in fact really the
whole integrated SDK of which that API is a part...
No! <slap slap> Wake up Tim, that was just a bad dream.
Here are a few paragraphs I wrote on the subject a couple
years back in another conversation, I found them archived
over in Dave-Winer-land:
It took me years to realise how deep and important
the divide is between wanting an SDK and wanting to know
the underlying protocol. Too much of our biz can only see
one of these realities. I grew up with networked
minicomputers and (mostly) Unix, and maybe that's why, in
the final analysis, I always want to see the bits on the
wire, because in the final analysis, given any programmable
device, I can work with them.
XML is of course the ultimate expression of that philosophy;
it can do a reasonably good job of offering a bits-on-the-wire
view of just about anything.
During the heydey of client-server I was repeatedly baffled
and frustrated by the mind-set, in particular evidence chez
Apple and Microsoft, that the only expression of computing
reality was a big hairy complicated API with an associated
big hairy complicated (and often expensive) SDK. This is not
just a Unix-vs-PC thing - the X window system is one of the
most extreme examples of the big, hairy, complicated, API (the
rumor that they ever actually fully documented the wire
protocol is false).
And not that this approach is wrong - I'm sitting in front
of a Windows box, and three of the windows are X applications
running on my big server which off at a distant ISP.
These days I write big complicated software in Java, which
does a good job of giving you a tractable object model
overlaying insanely complex infrastructure. But in a
distributed int[ra,er]-net scale app with heterogeneous boxes,
there's still no substitute for the bits on the wire.
Our profession needs to grow up a bit and actually arrive at
a consensus as to when each of these approaches is appropriate,
teach it in college, and so on.
And another reason that Sean is wrong is that it's taken,
in aggregate, in excess of 5 years to shake out the DOM and
the infoset, and if we'd held off on XML until we had a
consensus data model, we'd still be waiting.
At the end of the day Henry is right, you really need the
infoset for the same reason that SGML needed groves and
property sets, so that you can define higher-level protocols
like XPath XSL and XQuery and so on in a nice clean way.
So, spec writers need this apparatus. Does the actual
*programmer* need to think about it? Usually not; the
typical programmer's world-view is either that given by
some SDK (with access to SAX and/or the DOM) or in a really
heterogeneous system, bits-on-the-wire.
Clean abstract enhanced infosets are nice, but they're
really hard to load into emacs or IE5 and look at to
figure out what's going wrong [which I *always* end up
needing to do, maybe others are smart enough to avoid
XML was defined at a syntactic level for a reason. Those
who want to take another view can, and often it's useful
to do so. But let's not claim such a view is truer or
deeper in any universal sense. -Tim