[Xpath-ng] Positional predicates (WAS: Minimal FIXPath (with a bonus)?)

[David Carlisle]

  Third, should we drop positional predicates, such that people have to
  use the long hand [position() = N] rather than just [N], which would
  make optimisation easier. I'm more ambivalent about this, since it
  doesn't change the capabilities of the language, but again I'm not
  convinced that the cost in terms of usability is worth the gain in
  optimisation power.

I don't think you can drop the [1] syntax and have any user recognition
that this is a son-of-xpath as it is just so rare to find any Xpaths
without this, however my understanding of the optimisation problem is
that it isn't really positional predicates that cause the problem so
much as not knowing in time whether or not it is positional.

So I think we could consider a rule that made [...] positional
only if ... is known statically at compile time to be a number.

The simplest version of the rule would be that positional predicates had
to be of the form
[ optional-white-space numeric-literal  optional-white-space]
That would already catch a large percentage of current usage.

Depending on the static information that a fixpath processor ends up
having, one could imagine also allowing some expressions. (I hope we
don't end up with XPath2's static type system but some of the following
could be known to be numeric at compile time and could force the
interpretation of [] to be positional.

[ 1 + 2]

<xsl:variable name="x" select="1"/> ...  [$x]

[count(foo)]

David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________