Lists Home |
Date Index |
> I'd believe that if you showed me how in an XSLT2 stylesheet
> I could say
> If the XML parser has corrupted my data stop here so I can find a
> different parser.
Nothing has changed here except that the XPath2 spec is a lot more
explicit than the XPath1 spec was in saying clearly that you can
construct a data model any way you like.
We have seen interoperability problems with XSLT 1.0 because some
processors validate, some strip whitespace, some do XInclude processing,
some don't retain ID attribute information. There are also freedoms
available to implementors which none have chosen to exploit, such as the
freedom not to expand entity references. The variations as to how you
get from a source XML document to an XPath Document object are already
manifold; there's nothing new here in the 2.0 specs, other than further
variations that become possible in the way schemas are handled.
XSLT 1.0 and XPath 1.0 chose (in my view rightly) to assume a Document
object as input and to say nothing about how it was constructed, and
XPath 2.0 continues that tradition.
As it happens we are currently doing work to see if we can pin down the
processing pipeline from an XML source document to a Document object
rather more precisely, while still retaining user freedom to construct a
Document object from thin air. It's not easy because I think users need
control over this process. I would personally prefer to see it handled
by a separate W3C spec for processing pipelines.