Re: XPath 1.0 or 2.0

A few thoughts:

I agree that interoperability is an important issue. I also like when
specification don't introduce multiple level of compliance or optional
parts. However, I won't consider this as a absolute rule. If there are
good reason to do so, then I am fine giving options to people
implementing the specification.

Even if XPath 2.0 is not yet a W3C recommendation, 2.0 is where the
W3C is going. It has been quite stable for a while now, and some of us
have been using XPath 2.0 for years in real-world applications. Given
this situation, I think that we would need very strong arguments not
to go with the flow and to stay with XPath 1.0.

XPath 2.0 has a number of benefits over XPath 1.0. In my experience,
"if" is used very frequently. It is needed so often that when the
XForms 1.0 came out in 2003 when only XPath 1.0 was available, the
XForms WG felt that they had to add an if() function to XPath 1.0.
There are number of cases where the XPath 2.0 function library becomes
essential. Think about tokenize(), the date and time functions,
regular expression functions.

A very high quality open source implementation of XPath 2.0 is
available for Java and .NET in form of Saxon. For Java and .NET, XPath
2.0 is just available as an off-the-shelf component. I would predict
that most of the implementations of the pipeline language will run in
one of those two environments. We don't want to prevent someone from
writing an implementation in C or Perl, where an off-the-shelf XPath
2.0 component might not be available. But XPath 2.0 not being
available to C and Perl should not hold us in the past and force
everyone to use XPath 1.0.

Should we push the question of XPath 2.0 support to future version of
the pipeline language? If covering a feature in the specification is
complex, it is reasonable to consider pushing that feature to future
version of the language. But looking at the proposals that have been
made in the list during that last week, I see simple ways to support
XPath 2.0 in the pipeline language (more on this later).

For those reasons, I believe that the "standard" expression language
should be XPath 2.0. I second Jeni in her proposal to restrict
ourselves to the same subset of XPath 2.0 used in Basic XSLT 2.0. This
gives away all the complexity attached to schema and user-defined
types. In environments when XPath 2.0 is not available,
implementations should be allowed to use XPath 1.0 instead. Yes, this
unfortunately introduces two level of conformance. It is not ideal,
but I prefer this to throwing away XPath 2.0 altogether just because
we don't want to have 2 levels of conformance.

In short:

1. XPath 2.0 is where the W3C is going. We would need to make strong
argument not to follow the flow.
2. XPath 2.0 is a significant improvement over 1.0, in particular with
"if" expressions, and the functions and operators library.
3. XPath 2.0 is available as an off-the-shelf implementation at least
for Java and .NET. And arguably most of the pipeline implementations
will be done for Java and .NET.
4. We have a simple solution to support XPath 2.0 in the pipeline
language, namely restrict ourselves to the subset defined in XSLT 2.0
Basic.

Alex

On 5/17/06, Norman Walsh <Norman.Walsh@sun.com> wrote:
> 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.
>
>
>


-- 
Blog (XML, Web apps, Open Source):
http://www.orbeon.com/blog/

Received on Thursday, 18 May 2006 07:55:05 UTC