XPath version (Was: Comments from the XSLT WG on the XProc Last Call Document)

Speaking only for myself (again)...

Sharon Adler wrote:
> From: XSLT WG
> 4. We think it's shortsighted to be using XPath 1.0 rather than 2.0. At the
> very least, using XPath 2.0 should not be non-conformant.

As a user, I'd love to have the power of XPath 2.0 in XProc. As an
ex-XSL-WG member, it's frustrating to see a new specification that
doesn't use something we worked so hard over.

But as an XProc WG member, I think that we have to use XPath 1.0.

Our drive has been to get XProc 1.0 out of the door quickly, accepting
that it can't do everything, with the express intention to work on a
more powerful version soon afterwards.

In that context, we have to look at the *current* state of
implementation of XPath 2.0. We therefore ruled out using *only* XPath 
2.0 on the basis that it's a significant implementation burden (there 
simply aren't the same number of off-the-shelf XPath 2.0 implementations 
as there are XPath 1.0, particularly if you look at languages like 
Python or Ruby. So mandating XPath 2.0 would delay or prevent XProc 
implementations in those languages.

Of course we have to keep one eye on eventually upgrading to XPath 2.0.
"Backwards compatible mode" eases the transition substantially. But
perhaps the XSL WG's experience with moving from XSLT 1.0 to XSLT 2.0
could help us identify those areas that will cause us problems (Mike's 
already pointed out using an "empty root node" as a context node rather 
than specifying it as "undefined").

If we *do* decide to allow XPath 2.0 as well as XPath 1.0 then I think
we should have a lexically scoped flag (similar to the [xsl:]version
attribute) that indicates the XPath version in use in a particular
pipeline (library) -- xpath-version="1.0|2.0" -- and state that
processors that support XPath 2.0 must use backwards compatible mode if
xpath-version="1.0". If xpath-version="2.0" then XProc processors that
only support 1.0 should create dynamic errors (which can be caught when
used in a <p:try>) if they are asked to evaluate expressions that aren't
legal 1.0. And we'll need to note that options that take XPath
expressions can take XPath 1.0 or 2.0 as well. And add a p:xpath-version
system property. That's all doable as far as I can tell.

But personally, I'd rather avoid having different conformance levels if
we can, because of the extra complexity it brings for users. Certainly,
it should be acceptable to use an XPath 2.0 processor in backwards
compatible mode in XProc 1.0, but I'm wary of having some
implementations that support one and some the other. And I think we can
view XPath 1.0 as a simple XPath 2.0 subset as befits XProc 1.0, which
isn't a general purpose transformation language like XSLT.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Friday, 26 October 2007 19:11:18 UTC