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

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


mike@saxonica.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|XQuery                      |XPath
            Summary|[XQuery] Casting rules in   |[XPath] Casting rules in
                   |3.5.2 General Comparisons   |3.5.2 General Comparisons
                   |(editorial)                 |(editorial)




------- Comment #2 from mike@saxonica.com  2007-10-24 08:22 -------
Reassigned to XPath.

I realized that my rationale in comment #1 was OK in principle, but flawed in
the detail. Here is a better example.

Consider the following function

<xsl:function name="x" as="xs:boolean">
  <xsl:param name="y" as="xs:integer"/>
  <xsl:sequence select="exists($input//a[.=$y])"/>
</xsl:function>

where $input is untyped, and it is known that the <a> elements have values
whose lexical form makes them castable to integer.

Now it seems entirely unreasonable to me that this function should cause a
dynamic error when someone calls it supplying a value of type
xs:negativeInteger, merely because casting one of the <a> values to
xs:negativeInteger fails. The writer of the function should not have to defend
against that possibility.

Michael Kay

Received on Wednesday, 24 October 2007 08:22:36 UTC