Merging (Was: Re: [Xpath-ng] FIXPath (XPath NG core) straw man draft posted)

[Jeni Tennison]

Hi,

First off, Uche -- many many thanks for putting together the strawman,
it's incredibly useful.

I'm finding it hard to follow this particular thread about the merging
of lists of nodes, probably because I have the XPath 2.0 behaviour
floating about in the back of my mind.

I am strongly of the opinion that we must preserve XPath 1.0 behaviour
for positional predicates in location paths because XPath 1.0 users
will get very confused if we don't and because it gives the desired
results in most situations. In other words, given the example:

  <a><b><c/></b><d/><e/></a>

and the context node is c, then I think:

  ancestor:*/child::*

should result in

  (a, b, c, d, e)

I think that this means that I think that the current definition of
merge in the strawman is right.
  
I think that we also need to have a non-sorting, non-de-duplicating,
non-flattening operator that performs a mapping operation. For
example:

  ancestor::* => child::*

would return:

  (c, (b, d, e), a)

or possibly:

  (a, (b, d, e), c)

if we decide that the expression ancestor::* should return nodes in
document order, which could then be flattened, sorted and
de-duplicated with functions.

Note that this is the same as the for expression in XPath 2.0, but
more concise and with binding of the context item/position in the
'return' clause. The equivalent in the current draft of XPath 2.0
would be:

  for $a in ancestor::* return child::*

With both of these operations we should think about whether we can use
the same operators for atomic values. For example, it would be nice if
we could do:

  (1, 2, 3) => . + 3

to return (4, 5, 6) and, as in XPath 2.0 if we could do:

  ref/key('defines', @name)

to get the nodes that are referred to in the name attributes of the
ref elements.

Cheers,

Jeni

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