Re: XPath 1.0 or 2.0

A few thoughts:

There are lots of pipeline languages out there. Several of us on the
committee have written one (or more) of them. One of the most
important benefits (IMHO) of this WG is that we will produce a
*standard* pipeline language. That means I'll be able to send you my
documents and pipeline and you'll be able to process it, even if we're
on different platforms using tools implemented in different languages
by different groups.

If we produce a standard that has significant interoperability issues
at its core, I think we're introducing a very significant risk that
our standard will fail to gain adoption. If I can't send you my new
pipeline with confidence, then I might as well just keep on using the
tools I already have. And if I can't process your pipeline with
confidence, I don't know how to justify allocating resources to write
a processor for the language.

For these reasons, I think it would be a serious mistake to allow an
implementor or author to choose what version of XPath is to be used
for expressions in the core language.

I've reviewed our use cases and requirements document and I don't find
a single use case that obviously requires XPath 2.0 in the language.
If you have some in mind, please send them so that we can update the
use cases and requirements document.

While I'm a huge fan of XPath 2, I don't see a compelling need for
XPath 2 at the pipeline language level. I'm pretty confident that most
XPath expressions in core components will be simple element tests.

At the moment, XPath 2.0 is in CR. There is, to the best of my
knowledge exactly one complete implementation of it.

There are a bunch of us early adopters, who are using XPath 2.0 and
XSLT 2.0 with great delight. But I'm willing to bet there are far more
users that have no immediate plans to start using XPath 2.0. Certainly
not before XPath 2.0 gets to Recommendation.

Allowing XPath 2 in the language wouldn't provide any new
functionality, it would simply offer greater convenience for the tiny
minority of pipeline documents that have any need for XPath 2
expressions at all. Those pipelines can be written to use the XSLT 2.0
component to return a document that provides an answer that can be
evaluated with XPath 1.0.

For these reasons, I think it would be a mistake to require XPath 2.0
support in the language.

Adding support for XPath 2.0 to the language will require us to spend
some time considering how to get some level of schema support into the
pipeline language. I don't believe that any existing requirement or
use case imposes this burden on us or our implementors. I would really
rather not impose it simply to make a small percentage of uses more
convenient.

If, as many of us hope and believe, XPath 2.0 is wildly successful and
XPath 2.0 entirely replaces XPath 1.0 in a few years, there is nothing
that will prevent us from producing an XProc V1.1 language that
allows or requires XPath 2.0 expressions.

Implementors anxious to provide this functionality can do so
immediately with custom components. The success of such components in
the marketplace will provide a good barometer for the cost/benefit
analysis of providing XPath 2.0 support.

In short:

1. I think allowing a choice is unacceptably risky.
2. I think requiring XPath 2 is unnecessary.
3. Anyone anxious to use XPath 2 can do so even if we don't provide
   it in V1.0 of the language: authors can use the XSLT 2.0 component
   and implementors can provide custom components.

Let's choose XPath 1.0 for expressions in the core language.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.