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

[Joe English <jenglish@flightlab.com>]

Sean McGrath wrote:

> isn't it time to accept that not specifying formal
> post-parse data model(s) for XML 1.0 was a big
> mistake?

To a degree.  SGML made the same mistake initially -
without ESIS and (much later on) groves, it was difficult
to make much sense out of applications like HyTime.
But the Infoset and the notion of a PSVI seem to address
this issue pretty well, mostly.

(As an aside, I fear that another lesson learned from
the SGML experience is being forgotten.  In SGML,
validation was intimately coupled with parsing and
processing.  XML 1.0 largely avoided this problem,
but the latest batch of Recommendations in the pipeline
strike me as a bit over-reliant on XSD.)

> Furthermore, would the members of the list concur
> that there is an enormous difference between
> the data model needed for read only apps and
> the data model need for read/write apps.

Yes, but there's also a huge difference between the
data models needed for POP-oriented, MOM-oriented,
and RDF-based applications, and a huge difference
between the way XML applications written in Java,
Perl, and Haskell will represent the data.  I think
the Infoset editors did a pretty good job coming
up with a specification that's applicable to all
of these categories.

> Would the list accept that the read/write nature
> of the DOM makes life overly hard for developers
> of read only (and in particular persistent) DOM
> implementations?

No opinion here.  (There are *other* aspects of the DOM
that make life overly hard with the kinds of applications
I usually work with, so I don't end up using it very often
to begin with :-)

> Finally, would the members of the list agree
> that the read/write nature of XSLT is at the
> heart of the difficulties in scaling its query
> capabilities to the degree needed for purely
> read only use such as is required by XML
> Query?

Not really.  XSLT doesn't really have a read-write
processing model.  The input tree is never modified,
and result nodes, once constructed, are never changed
either.

I think it's XSLT's flexibility that makes it difficult
to optimize: since any template can potentially access any
part of the source tree, predicting access patterns is very
difficult.


--Joe English

  jenglish@flightlab.com