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

[Uche Ogbuji]

> 
> 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.

You mean that is how XPath 1.0 node sets are often interpreted, right?  The 
node sets themselves have no order.

That's not just to be pedantic, either.  It's part of what I think makes the 
whole matter non-obvious.  I'd like to be convinced that in the many different 
use cases one could construct with reverse node sets, a merge that maintains 
document order throughout doesn't cause significant deviations.

To go back to my example.  Document:

<a>
    <b>
        <c/>     <--- context node
    </b>
    <d/>
    <e/>
</a>

In XPath 1.0,

(ancestor::*/*)[1]

Would return

{c}

If the merge always resolves to document order, in FIXPath it would return

[a]

I know that this is hardly a very common case.  I suppose it wouldn't be such 
a big deal if it were the only sort of expression to be backwards 
incompatible.  My hesitation is that I may be missing more common cases.


> 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.

Good point.  We should loosen that restriction.


> > 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.

And remove dupes.


> I like this approach better, but it's a bigger change from XPath 1.

Hmm.  Or do you mean *don't* remove dupes?  I do think that would be too big a 
change.


> > 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.

I'll add it to the draft for straw man 0.2.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
A Python & XML Companion - http://www.xml.com/pub/a/2002/12/11/py-xml.html
XML class warfare - http://www.adtmag.com/article.asp?id=6965
MusicBrainz  metadata - http://www-106.ibm.com/developerworks/xml/library/x-thi
nk14.html