Re: Data Model(s) for XML 1.0 / XML Devcon / DOM / XSL / Query

[Tim Bray <tbray@textuality.com>]

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
>(http://www.xml.com/pub/a/2001/02/21/xmldevcon1.html).
>isn't it time to accept that not specifying formal
>post-parse data model(s) for XML 1.0 was a big
>mistake?
>
>Furthermore...

... 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 
this].

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