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

[Uche Ogbuji]

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

It was well worth the effort for the concrete discussion it seems to have 
stimulated.


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

OK.  I think I've been convinced of that now, except for the operand 
restrictions.

I'll re-word the issue attached to it.


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

Interesting thought.  Could this be done by a function?:

compose(ancestor::*, child::*)

I'd like to minimize new syntax if possible.

In fact, possible discussion point:  how about a principle that we will only 
add new syntax if it significantly helps improve extensibility.

I'd rather not add new syntax just to have neat new core features.


> 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::*

I think the functional approach I suggest is more general, and thus much more 
powerful (I would guess David R agrees ;-) )


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

Yes.  If we do use a functional approach, this would be quite possible, 
although it would be a different function.  Probably "map" rather than 
"compose" in association with some method of in-line function definition:

map(f(x): (x+1), [1, 2, 3])

yields

[2,3,4]

We can choose some other way to spell this, if we prefer.

However, I think both such facility and a compose function should be in 
separate modules than the core.  David probably has most of the underpinnings 
of such a module in FXPath.


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