[
Lists Home |
Date Index |
Thread Index
]
Hi David,
> So what does Xpath 2 do?
>
> Firstly it provides the bizarre => operator which is a restricted
> version of id(), then for all the new types it stresses the id()
> approach of inferring type information which might possibly be
> supplied by a suitable parser, rather than the approach that has
> proved far more robust, allowing the stylesheet to specify what
> types it wants to use for the content of certain elements.
To be fair, both XQuery and XSLT now have mechanisms for importing
schemas, so it's feasible for a stylesheet or query author to create
their own schema for the purposes of the query or stylesheet. This is
like using xsl:key, except that (a) it has to be specified in a
separate file and (b) you have to write it in XML Schema rather than
XQuery/XSLT.
There are still issues here: does the source document get validated
against this schema or the one that it declares? What if it's not
supposed to be validated against a particular schema, because it's
targetted at a secondary document? Do the users of XSLT really want to
have to learn XML Schema to take advantage of typing? Is XML Schema
the best language to use to express how to construct indexes of a
document, or is there a different formalism that's better oriented to
the requirements of XQuery or XSLT from a schema language? Should
XQuery and XSLT be tied to XML Schema at the expense of other schema
languages -- why can't you import a DTD to do the same thing, for
example?
I agree with the central point, though: the impression I have of XPath
2.0 is of a newly reinvented language that has been grudgingly forced
into backwards compatibility with XPath 1.0, rather than an
incremental development of existing XPath 1.0 functionality.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
