W3C home > Mailing lists > Public > www-xpath-comments@w3.org > July to September 1999

Re: XPath and XPointer

From: James Clark <jjc@jclark.com>
Date: Sun, 15 Aug 1999 12:13:16 +0700
Message-ID: <37B64C6C.786BB59D@jclark.com>
To: Michael Dyck <jmdyck@netcom.ca>
CC: www-xpath-comments@w3.org, www-xml-linking-comments@w3.org
Michael Dyck wrote:

Thanks for your intelligent comments.

> Paul Prescod wrote:
> > It seems to me that XPointer should only
> > extend XPath in ways that have been forseen in XPath.
> I agree. (In particular, I dislike the way that the "range" and "string"
> axes have been bolted onto the XPath framework. XPath's section 2.1 clearly
> lays out the semantics of an axis and the syntax of a basis, and neither
> "range" nor "string" conforms to *either* of these guidelines.)

I'm working with the XPointer folks to try and ensure that XPointer
extends XPath properly in future drafts.

> On the other hand, I think that the authors of XPath have a responsibility
> to foresee reasonable extensions, and allow for them.

Indeed.  But we also have a responsibility to get a solid spec out in a
timely manner.

>  To this end, I'll
> suggest a modification to the XPath grammar which should make extensions
> easier.  At its heart, my suggestion concerns the production for Basis:
> [5] Basis ::= Axis Name '::' NodeTest
>             | AbbreviatedBasis
> To this, I would add a third alternative, "PrimaryExpr". 

This doesn't quite work.  See


in the just-released XPath draft.  To make the semantics of [] work out
coherently, the [] in a location step needs to be treated as being in
the scope of the AxisName.

I would like eventually to see XPath generalized so that the right hand
operand of / could be an arbitrary expression.

The way I think this should be done is to make the syntax essentially:

Expr ::=
  Expr '/' Expr
  | AxisName '::' Expr
  | WildcardName
  | FunctionCallExpr
  | Expr '[' Expr ']'

with the appropriate precedence and associativity.  An important point
is that [] would have higher precedence than '::', so that


parses as


The current axis would then become part of the expression evaluation
context. With this generalization, text(), comment() etc become true
functions that return a set of nodes from the current axis.

XPath is designed so that the syntax in a future version can be
generalized in this way without compatibility problems. However, such a
change is not a small thing; it would need extensive consideration and
implementation experience.  Therefore I think it's better to leave it to
a future version of XPath.

> At first glance, you might rewrite
>         range::L1,L2
> as
>         range(L1,L2)
> However, the XPointer draft specifies that L2 should be evaluated in the
> context(s) yielded by L1, whereas XPath specifies (implicitly) that the
> arguments to a FunctionCall are all evaluated in the same context as the
> FunctionCall.

Right.  The XPointer range "axis" cannot be done as an XPath function.

> Therefore, to obtain the same semantics, you must rewrite
>         range::L1,L2
> as
>         L1/range(.,L2)
> For instance, the example from XPointer section 5.5.3:
>         range:: descendant::REVST, following::REVEND[1]
> would become
>         descendant::REVST/range(.,following::REVEND[1])

That's semantically consistent with XPath but it's not very pleasant.  I
think a better, simpler solution is just deal with the range "axis" as
special top-level syntax.  Instead of

 xptr(range::descendant::REVST, following::REVEND[1])

you would simply do:

 xptr(descendant::REVST, following::REVEND[1])

ie the SchemeSpecificExpr for xptr would be

  | Expr ',' Expr

I think that's enough for XPointer.

Received on Sunday, 15 August 1999 01:15:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:13 UTC