[Bug 5223] [XPath] Casting rules in 3.5.2 General Comparisons (editorial)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5223





------- Comment #4 from mike@saxonica.com  2007-10-29 09:03 -------
Thanks for your comment - your proposed reformulation of the type conversion
rule seems very precise and (speaking personally of course) I favour it.

We had a lot of debates about the "fail vs. return false" question. On the
whole I was personally inclined to favour the "return false" approach. In fact
this semantic is the one that was eventually adopted for some analogous cases
including the functions distinct-values(), index-of(), and deep-equal() (and
also for key() in XSLT). It's also (more-or-less) the semantics we adopted for
pattern matching in XSLT: a failure during attempted matching is treated as
no-match.

Although I would have preferred the "return false" behaviour, I don't think
there is any rationale that would justify a change to the spec at this stage.
However, there is some latitude under the "errors an optimization" rules.

Arguably a conformant implementation could exploit the "errors and
optimization" rules to deliver false for the general comparison "a"=3. In
section 2.3.4 we discuss the example //product[id = 47]. We say "if an
implementation can find (for example, by using an index) the product
element-nodes that have an id child with the value 47, it is allowed to return
these nodes as the result of the path expression, without searching for another
product node that would raise an error because it has an id child whose value
is not an integer." I think this includes the case where the set of product
elements with id=47 is empty; in this case we can return an empty sequence
without testing that all id's are numeric. That's equivalent to returning false
rather than an error from the general comparison.

There is of course one big disadvantage to returning false in such cases - it
makes it quite hard for the user who has made a genuine mistake (like writing
id=47 instead of id='47') to work out what has gone wrong. This I think is the
reason the spec is written as it is.

Michael Kay

Received on Monday, 29 October 2007 09:03:43 UTC