[Xpath-ng] My favorite XPath language]

[Uche Ogbuji]

> 
> Uche Ogbuji wrote:
> 
> > [Joe English]
> > > Number three is mandating IEEE floating point for numbers,
> > > complete with the rules for NaNs and infinities.  This is
> > > fine for Java implementations where all the world is a
> > > 32-bit CPU with IEEE 754 support, but it's a bit of a
> > > headache for most other languages (like C89, where 1.0/0.0
> > > is "undefined behavior" instead of +Infinity).
> >
> > I *hate* IEEE 754 as much as the next man, but I wonder what we would replace
> > it with.
> 
> Arbitrary- or fixed-precision rationals would be my choice, but
> just about anything else would do.  See DSSSL and/or Scheme
> for examples.  My main objection is that the XPath numeric
> datatype is overspecified.  For instance there is absolutely
> no good reason to mandate that "1.0/0.0" returns anything other
> than an error.  The rules for converting a number to a string
> are pretty bad too.  (I understand that even Java programmers
> have a difficult time getting this right.)
> 
> Most of all, floating point operations are almost never
> needed in typical document processing tasks.  TeX gets by
> without using them at all.  And the few places they are used
> in practice (computing totals on a balance sheet, etc.), they
> probably shouldn't be.

Strongly agreed with this point.


> > > > 2. What should be added to Xpath, and *why* can't we do without.
> > > > 3. Can't we create a better Xpath by taking things away?
> > >
> > > I think we could do without big chunks of the expression
> > > language, or at least factor those out into an optional module.
> > > Many XML APIs use XPath as an embedded sublanguage (like
> > > regexps, SQL, etc.), and since the host language usually
> > > has its own collection of arithmetic and string processing
> > > facilities there's little need to duplicate them in XPath.
> >
> > Hmm.  Again I wonder how all your suggestions square with backwards compat.
> > Do you think this shouldn't be a core goal?
> 
> Yeah, it probably should be.
> 
> I'd say we should aim for 99 and 44/100 percent compatibility
> with XPath 1.0, but shouldn't feel too bad if we fall short of that
> if the end result is a net gain in power, simplicity, or ease of use.
> 
> Making string and arithmetic options an optional module would
> be a win: no loss of power for clients like XSLT (which would
> include the module), and easier implementation for embedded
> APIs (which wouldn't need to).
> 
> Getting rid of the overloaded '[]' syntax is probably a non-starter;
> the hit to backwards compatibility is pretty big.

Agreed.

> Replacing node sets with node lists just might be a good tradeoff.
> It would have a subtle and possibly significant effect on existing
> XSLT stylesheets; on the other hand it could make XPath much
> easier to implement efficiently.  (My understanding is that XPath
> processors spend a lot of time sorting and removing duplicates,
> and/or spend a lot of effort trying to figure out when they don't
> need to.  Is that the case?  Since you've actually implemented
> one you know a lot more about it than I do :-)

Pretty much so.  Node sets in 4XPath are Python lists.  In some cases we have 
to use either Python dictionaries (hash tables) for efficiency, but because 
document order is so much of the typical state of things in XPath, lists are 
overall more efficient.  This, of course, leads to all sorts of contortions in 
certain areas.

As an implementor, I'm all in favor of moving to lists in the spec.  I know 
that some operations are more efficient if everything is designed as a set, 
but I think such considerations are just not as prevalent in common processing.

So, even though David Carlisle was reluctant in his conclusion, I strongly 
agree with it.  I think XPath NG should use lists, with nested lists 
permitted.  I think we can work it so that the effects on backward 
compatability are minimal.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/p
y.html
The Past, Present and Future of Web Services 1 - http://www.webservices.org/ind
ex.php/article/articleview/663/1/24/
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/in
dex.php/article/articleview/679/1/24/
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing - http://www-106.ibm.com/developerwork
s/xml/library/x-tipgenr.html