[Xpath-ng] My favorite XPath language]

[Joe English]

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.


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

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



--Joe English

  jenglish at flightlab.com