[Xpath-ng] Minimal FIXPath (with a bonus)?

[Jeni Tennison]

Hi Uche,

> I think callable objects are easy enough to implement, as long as
> your parser is structured so you can call it from the host language
> implementation in a straightforward manner.
>
> I don't honestly know how big this burden is. From what I recall
> hearing, Microsoft didn't like dynamic features in XPath 1.0 because
> it seemed to them to preclude some really hard-core optimizations.
> However, if they're supporting the looping syntax you explain for
> XPath 2.0, I guess they've dropped that argument.

Perhaps MS was objecting to having strings be interpreted as function
definitions on the fly? Expressions such as location paths, predicates
and the new for expression don't have that problem. dyn:evaluate(),
saxon:expression() and the mooted function() function would have that
problem.

> Basically, I can't imagine why it would be harder to implement
> callable objects than it would be to implement any dynamic features,
> including a looping operator that allows arbitrary computations on
> each iteration.

OK.

[snip]
>> I think that we should be aiming for the core to:
>> 
>>   1. put in place the fundamental syntax that FIXPath processors must
>>      be able to parse
>> 
>>   2. address 80% of the requirements of the *small* uses of XPath,
>>      namely XML Schema and XForms
>> 
>> I don't think that FIXPath core should attempt to address 80% of XSLT
>> users' requirements, for example. I'm very happy to not have a
>> looping/mapping construct in the core if the fundamental syntax will
>> allow one to be added in a separate module.
>> 
>> With that in mind, I'd suggest stripping out all the axes aside from
>> child, attribute, descendant-or-self and parent (i.e. only keeping
>> those that are used in abbreviated syntax). I'd suggest keeping out
>> all the EXSLT functions from the core, and indeed stripping out some
>> of the existing functions. Basically, I think that FIXPath core should
>> take things away from XPath 1.0 rather than just adding to it... But I
>> should put this in another thread...
>
> This appeals strongly to me. The only thing that I balk at is that
> it would mean the core is not backwards compatible on its own.
> Therefore I would want to maintain an "XPath 1.0 basics" module in
> pretty close step with the FIXPath core, and have us define an early
> profile of core + this additional module which would guarantee the
> maximum backwards compatibility.

Yes, that's precisely how I see it working.

> Bonus: Another *huge* advantage of this is that we could make the
> FIXPath core streamable (i.e. I would suggest even stripping parent
> axis).

I think that's a good thing to aim for. I'd also suggest limiting
predicates to positional predicates in the core version, or perhaps
omitting them altogether (XML Schema doesn't use them). Since we want
to allow things that aren't actuallly used in the minimal FIXPath,
perhaps we're actually talking about two things:

  - a core, extensible syntax
  - a subset of that syntax used for a minimal FIXPath

Cheers,

Jeni

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