Re: XPath and XPointer

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

  http://www.w3.org/TR/xpath#section-Location-Steps

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 ']'
  etc

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

  ancestor::child[2]

parses as

  ancestor::(child[2])

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 ',' Expr

I think that's enough for XPointer.

James

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