RE: [XPath] Backwards compatibility of A<B

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 &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:54:40 UTC