[
Lists Home |
Date Index |
Thread Index
]
From: "Elliotte Rusty Harold" <elharo@metalab.unc.edu>
> I simply do not believe the Ogbuji/Kay position that any preprocessing
> as the source tree constructed is legal according to XSLT 1.0, for
> reasons I have elucidated elsewhere in this thread.
I think you are making the reasonable mistake of thinking that when
W3C Specs (except XML 1.0 itself) talk about XML they mean
XML. Instead, they mean XML-ish AVTs that may (or may not)
have one (or more) serializations to XML.
Take the XML Infoset. XML-DEV had this exchange a couple of days ago
Tim Bray wrote:
> Except for, there's no de facto or de jure way to exchange an infoset as
> an infoset.
John Cowan responded:
>The de jure way to exchange infosets is as XML documents. It's possible to
>construct an infoset that doesn't correspond to any XML document, though.
but a day earlier:
> Why can't the syntax and the infoset just be two ways of looking at the
> blackbird? Light is the left hand of darkness, darkness the right hand of light.
as if they were two sides of a coin. If there are synthetic infosets with no
serialization that are still "XML Infosets" then they are not just two ways
of looking at the blackbird. I think John is right that having the infoset spec
distinct from the syntax spec only reinforces this disconnect.
When XSLT 1.0 says it "is a language for transforming XML documents into
other XML documents" surely it means that we can treat infosets that are
possible but not serializable as pathological cases.
XSLT delegates its detailed model to XPath. XPath says
"XPath operates on an XML document as a tree."
Then it provides a mapping from its notions to XML Infoset notions.
So the motherhood statement in the XSLT abstract, which talks about XML
documents being the domain of the specs, gives way to practical details
given in terms of an infoset. And because the "XML" infoset does
not have the discipline of corresponding to XML, but exists independently,
the references to XML in W3C documents cannot really be taken
at face value, as long as people say that an infoset with no corresponding
XML document is legitimate. Instead, such an infoset should be considered
invalid or non-well-formed.
Instead, when it says "XML Infoset", we probably should read "DOM Infoset".
And, finally, to the extent that we have been talking about whether an XSLT
processor should perform its own proprietary transformations on data coming
in from an XML document, who are we kidding? Of course vendors should
add value whereever they can, at user option, but the default operation of
"standards" should be that they operate vanilla, giving the same result as
a correct implementation from a competitor.
Cheer
Rick Jelliffe
|
