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

[Uche Ogbuji]

[SNIP (more on the rest in another subthread)]

> The reason that I've steered
> towards saying that callable objects should be in a separate module
> rather than the core is that I imagined they were (a) hard to
> implement, (b) overkill for the small implementations such as
> XPath-in-XML Schema or XPath-in-XForms, (c) hard for users to get a
> grip on.
> 
> What's your assessment of the implementation problems? Would small
> implementations be able to support callable objects?

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.

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.

But all that aside, your post has given me a perspective that did occur to me 
much earlier, but that I didn't really think of when I prepped the straw man.  
That is of making FIXPath core much simpler than XPath 1.0.


> would provide the simple mapping operation that I'm keen on (the only
> difference being that the result list is flattened).
> 
> >> 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.
> >
> > I would *really* like for there not to be so much overlap with such
> > different syntax between what goes in the core and what goes in a
> > higher-order module. But I'm sensing that might be inevitable. If
> > so, then I'd at least like to at increase the generality of what's
> > in the core more towards the 80/20 point that I believe is typical.
> 
> 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.

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 I'll try to find time to experiment with this today...


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