- From: Michael Rys <mrys@microsoft.com>
- Date: Wed, 18 Feb 2004 13:54:33 -0800
- To: "Michael Kay" <mhk@mhk.me.uk>, <public-qt-comments@w3.org>
Could we use similar rules (using fn:Boolean() in BCM) to solve the EBV discussion we had? Thanks Michael > -----Original Message----- > From: public-qt-comments-request@w3.org [mailto:public-qt-comments- > request@w3.org] On Behalf Of Michael Kay > Sent: Wednesday, February 18, 2004 1:49 PM > To: public-qt-comments@w3.org > Subject: [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 <= @f and @f <= > $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 <= 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:54:40 UTC