[
Lists Home |
Date Index |
Thread Index
]
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.
It is true that it probably conforms to the spec if an xslt engine
always returns the (Xpath data model corresponding to)
<x>hello</x>
whatver URI is passed in as the argument.
But in practice they don't do that.
We have seen interoperability problems with XSLT 1.0 because some
processors validate, some strip whitespace,
Validation isn't really a problem (assuming the document's valid) what
would be a problem is if the non validating parsers didn't default
attributes and report IDs specified in external entities, but as far
as I've seen all the main ones do. Microsoft's stripping of white space
is by far the major source of inoperability between XSLT 1
applications. XSLT2 could have been a good time to have given facilities
in the stylesheet to avoid that inoperability rather than make a virtue
of it.
there's nothing new here in the 2.0 specs, other than further
variations that become possible in the way schemas are handled.
That is just a legalistic phrasing that does not reflect the reality
that there is nothing in XSLT 1 that approaches the scale of incompatibilities
that are introduced by the Xpath 2 data model's sanctioning of
systems that throw away everything in the original markup and just
reconstruct some new document from the typed data.
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.
Yes that would be good, but note while such a scheme could easily be
added to XSLT 1 to give more user control (do or don't strip space,
do or don't do xincludes, etc) It would be hard to usefully add
anything to Xquery if it stays as it is currently drafted and explictly
sanctions systems that only use typed data and don't have any mechanism
of keeping the original text. Well I suppose they could issue a fatal error
if asked to preserve the initial character data, that would be better
than the current draft's position of sanctioning the silent corruption
of data.
David
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
|
