[Xpath-ng] FIXPath (XPath NG core) straw man draft posted

[Joe English]

Uche Ogbuji wrote:
> Berend de Boer wrote:
> > Section "Overview"/*
> >
> > Issue: */ The merge operation is defined with location paths in mind.
> > But what about reverse axes? Des this mean that a merge cannot always
> > resolve to document order?
> > [...]
> > Merging two lists, sorting them by the node id will produce the asked
> > for result, so it's not an issue IMO.
>
> [...]
>
> My thinking was that if a merge operation occured in a situation such as
>
> ancestor:*/child::*
>
> i.e. the LHS returns the nodes in *reverse* document order, does this cause
> any problem that the result of the overall expression forces everything back
> to forward document order because of the merge?

That might be desirable.  The result of any multi-step
location path will be a list in document order with no
duplicates, which is compatible with XPath 1 node sets.

But there is a problem.  Since the "merge" operation
in the draft is only defined on lists in document order,
the result of e.g., "ancestor::*/preceding-sibling::*"
would be undefined.

> If my doc is:
> <a><b><c/></b><d/><e/></a>
> and the context node is c, then I think I would expect
> ancestor:*/child::*
> to result in
> [c, b, d, e, a]

IOW, instead of merging the result lists, simply concatenate them.
I like this approach better, but it's a bigger change from XPath 1.

> But the way I have merge in the straw man, instead we'd get
>
> [a, b, c, d, e]
>

> Side note: I guess we really need a sort-doc-order() function for lists.
>

Yes, definitely.


--Joe English

  jenglish at flightlab.com