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

[Uche Ogbuji]

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

Hmm.  I'm just thinking from an implementation POV.  I don't see the 
difference in terms of implementation between defining *static* callable 
objects, which is all I'd say is needed in the core, and loop expressions from 
XPath 2.0.

i.e.

for i in (1,2,3) return i + 1

can be implemnented exactly as

f(i): i + 1; f(i) for i in (1,2,3)

Just to pick a more general possible syntax (not that I'm necessarily 
suggesting it).

The latter does give the *option* that

f(i): i + 1

could stand alone as a function definition in a functional module, but in the 
core it could be limited to static use in looping constructs.

Same argument then applied to

for function(". + 1") over (1,2,3)

For example.  It's just different syntax, as long as "function()" is 
restricted to be static in the core.

I'm still trying to think of a compromise for functions and looping that meets 
the readibility/extensibility/generality sweet spot.  DIfferent subthread, 
though :-)


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

Would it be simpler to just add in all the syntax elements we expect to use in 
the core FIXPath, but declare some to be reserved for later modules?  It 
worked for colons in XML 1.0.  (or did it? ;-) )

Another option: just loosen the restriction that higher-level modules 
shouldn't change the syntax.  If we could establish clear dependencies between 
modules, we could just make sure that all modules that need a particular bit 
of syntax build on another that provides it.  And we don't know how clear our 
crystal ball is of syntax needs.

I'm not necessarily advocating this yet.  It's just a thought.


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