W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > November 2007

Re: XPath version

From: Alex Milowski <alex@milowski.org>
Date: Mon, 12 Nov 2007 13:16:18 -0800
Message-ID: <28d56ece0711121316s725012e7o30b315ef316333c4@mail.gmail.com>
To: public-xml-processing-model-wg@w3.org

On 11/12/07, Jeni Tennison <jeni@jenitennison.com> wrote:
> Alex Milowski wrote:
> > On 11/9/07, Jeni Tennison <jeni@jenitennison.com> wrote:
> >> <p:xslt>
> >>    ...
> >>    <p:param name="monthName"
> >>      select="/months/month[position() = substring($date, 6, 2)]">
> >>      <p:document href="months.xml" />
> >>    </p:param>
> >>    ...
> >> </p:xslt>
> >
> > Wrapping the right-hand side in a number() function call would fix
> > this for XPath 2.0
> > while keeping XPath 1.0 compatible.
> Yes, I am aware of that. The point is that it's easy to write
> expressions that work fine in XPath 1.0 and don't work in XPath 2.0.
> That being the case, it's not enough to tell users to use XPath 1.0
> expressions to guarantee compatibility across processors. You have to
> say "use XPath 1.0 expressions with explicit casting using the string(),
> number() or boolean() functions in cases where XPath 2.0 would give you
> a dynamic error, specifically where you supply a value of one datatype
> where another datatype is expected, and using a [1] predicate where you
> supply a node-set containing more than one node where a single node is
> expected."

I assumed you were aware of that. :)

I'd be very happy to have a note that details this kind of example.

> Another way of putting it is that the expression must be *both* legal
> XPath 1.0 and legal XPath 2.0; that intersection is probably going to be
> the easiest thing for editors/lints to test.

You must mean this with the preface "if you want it to inter-operate
between XPath versions".

> (I still think the expected XPath version should be made explicit.)

So, if that attribute was present, is it informational or do you
if you know you can't support it?  Or are you allowed to attempt the pipeline
knowing that things might go wrong?

For example, if the user says xpath-version="2.0" but only uses simple
expressions, a implementation with only XPath 1.0 laying around might
be able to run the pipeline.  Is that OK or are they non-conforming?

Having a version attribute for XPath means that we have to be very
explicit about
all of this.

We could allow the XPath version to just be metadata with no attached semantics.
Regardless of whether we attach some kind of functional meaning to the version,
users will abuse the version (e.g. get it wrong or forget to change
it).  Assuming
they do not error on the version, what is wrong with letting the implementation
issue warnings for things it thinks may work (e.g. simple expressions
from XPath 2.0
that are syntactically XPath 1.0 expressions on a XPath 1.0 implementation)?

At least you could inspect the pipeline and understand from author
intent whether
the pipeline should work and we don't have to go through all the combinatorics
of possibilities.  In the end, you only have the XPath implementation
that you have
and the expression is either going to work or not.  Whether it gives
you the right
answer depends on whether the XPath has the same semantics in XPath 1.0 versus
2.0.  If it doesn't, go see the XSL/XQuery working groups.

Over time, things will converge to XPath 2.0 and hopefully future
versions of XPath
will have less backwards compatibility issues.

--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language

Bertrand Russell in a footnote of Principles of Mathematics
Received on Monday, 12 November 2007 21:16:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:45 UTC