[Xpath-ng] Positional predicates (WAS: Minimal FIXPath (with a bonus)?)

Uche Ogbuji uche.ogbuji at fourthought.com
Wed Jan 8 15:31:48 MST 2003


> 
> Jeni Tennison wrote:
> 
> > [...] I'd also suggest limiting
> > predicates to positional predicates in the core version, or perhaps
> > omitting them altogether (XML Schema doesn't use them).
> 
> I'm strongly in favor of omitting positional predicates,
> and using a different syntax for selection by position
> (perhaps an infix operator "list # n", or a function
> "nth(list, n)").
> 
> This would be a significant simplification.  The dynamic
> parts of the evaluation context -- the context size and
> context position -- would no longer be needed, leaving
> only the static parts.  It would remove one of the major
> obstacles to optimization (you can't optimize "expr[$n]" without
> knowing if $n is a number or something else).  In the absense
> of "last()", fully lazy evaluation becomes possible.  It would
> make predicates associative -- (expr[p1])[p2] = (expr[p1][p2]) --
> which is not the case in XPath 1.0.  Some of the most
> obscure and confusing parts of the XPath spec could be
> removed.
> 
> The "foo[n]" syntax in XPath is a DWIM gone bad.
> I think we should drop it, if we can get away with it.

Compelling argument, but your last clause is the rub.  I'm not sure we can get 
away with it.   I think /foo[1]/bar[2] is just too strongly embedded in 
consciousness, not to mention other specs.

What do others think?


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





More information about the Xpath-ng mailing list