[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