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

[Jeni Tennison]

Hi Uche,

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

Can you explain what you mean by "the operand restrictions"?

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

Only if we introduce a 'function' value. For example, the above would
currently call the compose() function with arguments being the
ancestors of the current node and the children of the current node.
What you're after is something like:

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

where the function() function creates a function value from a string.

> I'd like to minimize new syntax if possible.

I'd like to minimize new data types if possible, at least in the core.
I definitely think we should have a functional module that includes a
function data type and methods for generating function values, but I
really don't think we want to do that in the core.

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

I personally believe that there are two extra expressions that we
should include in the core: a conditional expression and a
mapping/looping expression. I view these as much more important (for
the core) than many/most of the XPath and EXSLT functions and the
inclusion of non-abbreviated axes.

The principle that I've been applying when considering whether
something should be in the core or in a separate module is that I
think it should be possible for a parser written based on the FIXPath
core to be able to parse any FIXPath expression, even if it can't
evaluate that expression (because it includes extension functions/axes
etc. that the implementation doesn't understand). Do you think this is
a reasonable goal?

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

That's certainly true, but I think that you'll agree that:

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

or:

  for (1, 2, 3) return . + 3

is much more readable/usable than:

  map(function('. + 3'), (1, 2, 3))

or:

  map(f($x): $x + 1, (1, 2, 3))
  
We should be careful to balance generality and power with usability.

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

As I've explained above, I agree that we want this full functional
power within a separate module. But I think that we should provide a
core set of that useful functionality in the FIXPath core.

Cheers,

Jeni

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