RE: [Moderator Action] "Bug" in XML Path Language (XPath) Version 1.0 W3C Recommendation 16 November 1999

A personal response, not on behalf of the WG:

The specification never states that every possible IEEE 754 number can be
represented as a literal, and I think this was never intended.

Of course you can write a minus sign in front of a number in any context
where a number is permitted; but it is regarded as a unary operator, not as
part of the number token itself.

XPath 2.0 will adopt the primitive data types of XML Schema, which will
allow you to use any lexical representations of numbers that are permitted
in the Schema specification.

Mike Kay

> -----Original Message-----
> From: Janko Stamenovic [mailto:janko@teletrader.com]
> Sent: 09 July 2001 11:40
> To: www-xpath-comments@w3.org; jjc@jclark.com; Steven_DeRose@Brown.edu
> Subject: [Moderator Action] "Bug" in XML Path Language (XPath) Version
> 1.0 W3C Recommendation 16 November 1999
>
>
>
> Hello,
>
> It seems to me that the specification is a little incomplete
> in the grammar
> part?
>
> I know that it states:
>
> "XPath is intended primarily as a component that can be used by other
> specifications. Therefore, XPath relies on specifications
> that use XPath
> (such as [XPointer] and [XSLT]) to specify criteria for conformance of
> implementations of XPath and does not define any conformance
> criteria for
> independent implementations of XPath."
>
> But on the other hand, it made confusion to implementors because of:
>
> "[30]    Number    ::=    Digits ('.' Digits?)?
>    | '.' Digits
> [31]    Digits    ::=    [0-9]+ "
>
> I expect that good implementation MUST behave according to IEEE 754
> standard, as in other XML specifications. That this was a
> real idea of XPath
> I conclude from the same document:
>
> "3.5 Numbers
> A number represents a floating-point number. A number can have any
> double-precision 64-bit format IEEE 754 value [IEEE 754].
> These include a
> special "Not-a-Number" (NaN) value, positive and negative
> infinity, and
> positive and negative zero. See Section 4.2.3 of [JLS] for a
> summary of the
> key rules of the IEEE 754 standard."
>
> As far as I understand, not handling IEEE 754 numbers IS A BUG in the
> implementation, and, sadly, the specification is clearly
> incomplete (because
> of the grammar).
>
> It seems that the grammar shown in XPath spec would not work
> even for the
> simplest cases, since it does not cover negative numbers.
> Even in errata
>  http://www.w3.org/1999/11/REC-xpath-19991116-errata/)  seems
> that nobody
> saw the obvious problem that only adding sign still does not
> correct the
> buggy grammar?
>
> I believe that a correctly written grammar should specify
> "numbers" as all
> possible IEEE formatted numbers, with
>
> a) optional sign, mantissa in which can optionally appear a
> '.' and optional
> positive and negative exponent, separated by 'E' or 'e' from
> mantisa, or
> with
> b) (optional sign) 'INF' or with
> c) (optional sign) 'NaN'.
>
> Or, as another possibility, it should simply not specify
> number format at
> all and clearly direct to more relevant specification.
>
> I await your opinion in order to be able to
>
> 1) Complain to implementors of XPath who do not handle IEEE numbers,
>
> 2) Prove in my company that we should stick to the IEEE norms.
>
>
> Thank you,
> Janko Stamenovic
> Teletrader AG
> Vienna, Austria
>

Received on Wednesday, 11 July 2001 09:57:33 UTC