[XPath] Backwards compatibility of A<B

This comment builds on one aspect of David Carlisle's XSLT 2.0 comment

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0856.html

David reported:

<dc>

  Less-than and greater-than comparisons between strings have changed
since XPath 1.0

 <xsl:variable name="a" select="mn[1]/text()"/>
 <xsl:variable name="b" select="mn[2]/text()"/>
 <xsl:for-each select="$enum[@fname=$fpname]/v[$a &lt;= @f and @f &lt;=
$b]">

which is checking that three "numbers" obtained from the source files
satisfy a constraint that one lies between the other two.

Is it really necessary for this to break in BC mode?
Is it not possible for the mapping of &lt;= to the underlying F&O
operators is changed in BC mode to more closely match the behaviour in
1.0? While this is annoying it is actually less trouble to fix than the
previous error, especially in this case, where the node sets such as @f
in the expression really are only going to return one node  so I would
just need to add a couple of instances of number() (I hope:-) However if
tehre are cases where the implicit existential quantification are used,
it will be tricky for an end user to get right (easier for the system, I
would have thought).

</dc>


First, an observation which I have made before but which may have been
lost:

Section 3.5.2 currently says:

If XPath 1.0 compatibility mode is true, and at least one of the atomic
values has a numeric type, then both atomic values are cast to to the
type xs:double.

It should say:

If XPath 1.0 compatibility mode is true, and one of the atomic values
has a numeric type and the other does not, then the value that does not
have a numeric type is converted to a double using the fn:number
function.

(There are two changes here. Firstly, a value that is numeric is not
changed, so a decimal comparison remains a decimal comparison. Secondly,
the conversion is done using the number function rather than casting, so
that "abc"<3 gives false rather than an error.)

Second, a proposal to address David's concern about the compatibility
problem.

I suggest that in the case where both operands of <, >, <=, or >= are
untypedAtomic, we should in BCM replicate the 1.0 behavior, but with a
strong encouragement to implementors to issue a warning.

Specifically: change rule 2 of 3.5.2 as follows. (The rules also need to
be arranged so rule 2b takes precedence over the current rule 1):

2. If backwards compatibility mode is true, then:

  2a. If one of the atomic values has a numeric type, and the other does
not, then the value that does not have a numeric type is converted to a
double using the fn:number function.

  2b. If both of the atomic values have the type xdt:untypedAtomic, and
the operator is one of <, >, <=, or >=, then both of the atomic values
are converted to doubles using the fn:number function, and the processor
should output a warning indicating that the comparison would be
performed as a string comparison if backwards compatibility mode were
false. The format and destination of this warning is
implementation-defined. The warning may be output either during the
analysis phase or during the evaluation phase.

(Note: XPath 1.0 would attempt a numeric comparison even if one of the
arguments was a string. So there is still a backwards incompatibility.
However, it is far less likely to arise in practice.) 

I've made the warning a "should" rather than a "must" because there are
environments where there is no way of communicating with the stylesheet
author, and in any case we can't legislate against it being sent to
/dev/null.

Michael Kay

Received on Wednesday, 18 February 2004 16:48:22 UTC