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

[Jeni Tennison]

Uche wrote:
> Joe English wrote:
>> I'm strongly in favor of omitting positional predicates,
>> and using a different syntax for selection by position
>> (perhaps an infix operator "list # n", or a function
>> "nth(list, n)").
>> 
>> This would be a significant simplification.  The dynamic
>> parts of the evaluation context -- the context size and
>> context position -- would no longer be needed, leaving
>> only the static parts.  It would remove one of the major
>> obstacles to optimization (you can't optimize "expr[$n]" without
>> knowing if $n is a number or something else).  In the absense
>> of "last()", fully lazy evaluation becomes possible.  It would
>> make predicates associative -- (expr[p1])[p2] = (expr[p1][p2]) --
>> which is not the case in XPath 1.0.  Some of the most
>> obscure and confusing parts of the XPath spec could be
>> removed.
>> 
>> The "foo[n]" syntax in XPath is a DWIM gone bad.
>> I think we should drop it, if we can get away with it.
>
> Compelling argument, but your last clause is the rub. I'm not sure
> we can get away with it. I think /foo[1]/bar[2] is just too strongly
> embedded in consciousness, not to mention other specs.
>
> What do others think?

I think that Joe's merged three arguments here.

First, could we drop last() in order to enable lazy evaluation. I
think that our Minimal FIXPath spec could do this -- it would be in
the spirit of making FIXPath streamable, wouldn't it? On the other
hand, the construction:

  <xsl:for-each select="item">
    <xsl:value-of select="." />
    <xsl:if test="position() != last()">, </xsl:if>
  </xsl:for-each>

is so common in XSLT that I wouldn't want to see last() disappear
entirely.

Second, should the context size and position should be available
within a predicate? If they weren't it would make predicates
associative. Unfortunately, it would also make it impossible to do
useful things like:

  item[position() mod 2 = 1]

which is again among the more common constructions we see in XSLT
(used to process just the odd-numbered items, in order to arrange them
into two columns, for example). I don't think that associative
predicates is worth this cost.

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.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/