[
Lists Home |
Date Index |
Thread Index
]
On Mon, 2002-08-19 at 16:24, Tim Bray wrote:
> Amelia A Lewis wrote:
> > On Mon, 2002-08-19 at 13:47, Erik Wilde wrote:
>
> >>i honestly don't see the point. people working with dom or sax or xslt
> >
> > Horsefeathers.
> >
> > DOM and SAX are pre-infoset APIs.
>
> Indeed. XML 1.0 is defined *only* at the syntax level. The infoset is
> an afterthought which turns out to be real useful to w3c spec authors.
Generally speaking, yes. The Schema working group defined a significant
set of extensions to the infoset, and I don't know (at present) of an
effort to supply that sort of enhancement at the SAX level. The
XQuery/XPath 2.0/XSLT 2.0 effort has defined, instead, a "datamodel,"
with a simplified set of node types.
The point of this is that the infoset effectively describes a "core" of
XML 1.0 + Namespaces that every API should implement. Call it an
abstract API. Can I get an element information item? How? Namespace?
How? And so on.
This works, in my opinion, not because of messes like the PSVI, but
because it describes XML 1.0 + Namespaces. Extending it to create a
concept of the Post Stylesheet Transformation Information Set (which
contains source information items, transformation information items, and
result information items) (yes, I'm making up something silly on the
fly; sadly there are examples out there that are equally silly,
presented with complete seriousness) doesn't help much of anything. For
extensions, the question of how the additional information items are
supplied begins to become really important.
Let's do an example:
<xyzzy xmlns="grue:underground.empire/great">
<!-- stuff -->
<possessions>
12
</possessions>
<!-- more -->
</xyzzy>
Add that the schema defines the possessions element to be a positive
integer with an upper limit.
Create a TypeHandler in SAX. This turns out to be a problem. Clearly,
you want to be able to signal a type (an identifier for the type) and a
value; this means that there is significant overlap with the "regular"
handlers. Double-reportage, in short, and the usual problems of
synchronization. The problem becomes acute if there is a desire to
create a mostly-PSVI, falling back to plain-old-content if the content
is well-formed, but not valid (this happens a lot more often than the
folks who write the specs seem to think). Issues arise of: does the
type information arrive first or last? How do multiple extensions
interact? What order are the information items delivered in, when
multiple extensions (or the core and one or more extensions) overlap?
This is a problem for SAX and similar streaming/message-oriented APIs,
but such APIs tend to be best-suited for the parse.
So, when I encounter expressions of interest in "extending the
information set," I tend to snarl. This is particularly the case when
examples of "infoset implementations" include the DOM.
Amy!
--
Amelia A. Lewis amyzing@talsever.com alicorn@mindspring.com
I don't know that I ever wanted greatness, on its own. It seems rather
like wanting to be an engineer, rather than wanting to design something,
or wanting to be a writer, rather than wanting to write. It should be a
by-product, not a thing in itself. Otherwise, it's just an ego trip.
-- Merlin, son of Corwin, Prince of Chaos (Roger
Zelazny)
|
