[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Infoset as subset of useful
- From: Tim Bray <firstname.lastname@example.org>
- To: email@example.com
- Date: Fri, 06 Jul 2001 22:43:24 -0700
At 11:15 PM 06/07/01 -0400, Simon St.Laurent wrote:
>I can't say I've found any use for the Infoset as currently written,
>except as a contributor of such fine terms as "element information item"
>which litter the landscape of XML verbiage.
There are two plausible reasons for having something like an
- it's much easier to write specs for things like schemas and
xpointers and so on in terms of infosets rather than syntax.
- we'd like the view of XML offered by DOM, SAX, and any other
API to be consistent, and the infoset ought ideally to provide
a foundation for maintaining consistency.
Empirically, the second of these doesn't seem to hold water,
because the XML APIs substantially predate the infoset and
seem to be interoperable in a surprise-free way for real-world
applications. As for the first, I personally believe that
it's possible in principle to write those specs with reference
only to syntax, but accept that the cost-benefit trade-off in
doing so may be lousy.
There is another motivation for doing an infoset - some folks
are really troubled that an XML document is an object defined
at the level of syntax; they feel that the data objects
represented by the syntax are the important, central thing,
and that the syntax is an ephemeral side-effect. If you buy
this, there is a plausible argument that you ought to start
from the infoset and then build one or more syntaxes for it,
which is my understanding of what ASN.1 does.
I'm on the record as feeling that this whole line of argument
is deeply incorrect, and that specifying XML at the syntax
level was the right way to go.
But hey, in another 10 or 20 years we'll know for sure, and
with luck, most of us will be alive to reflect on the lesson.
PS: I'm sure this story has been told here, but in case I'm
wrong, sometime back in 1996, in an XML WG telecon, somebody
said, "Uh, shouldn't we define an API for this thing?" and
James Clark said (I paraphrase) "Different kinds of programs
need different kinds of APIs, so it would be pointless to
specify just one" and everybody said "oh, of course" and the
discussion was over in about 2 minutes and it never came back.