[Bug 2324] Value/General comparisons: type promotion for xs:anyURI/numeric

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

           Summary: Value/General comparisons: type promotion for
                    xs:anyURI/numeric
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XPath
        AssignedTo: chamberl@almaden.ibm.com
        ReportedBy: frans.englich@telia.com
         QAContact: public-qt-comments@w3.org


Hello,     
     
The treatment of operands in value comparisons does not include a type    
promotion of xs:anyURI to xs:string. One result of this is that the following    
expression fails to compile:  
    
xs:string("example.org/") eq xs:anyURI("example.org/")    
    
due to no eq-operator existing between those two types.    
    
If this is intentional, I can understand the design since it is a stricter type    
checking in the spirit of much else in XPath 2.0.    
      
This was first brought up in a thread[1] on the saxon-help list, where Michael    
Kay added the following comments:    
    
<quote>    
I' confident it was the intention of the working group that value    
comparisons between anyURI and string should work, for example this is    
necessary to retain backwards compatibility for the expression    
    
<xsl:if test="namespace-uri() = 'http://thing/'">    
    
(if URI-to-string promotion doesn't work for value comparisons, then it    
doesn't work for general comparisons either).    
    
But I agree, if you follow the spec closely, there's nothing that causes    
type promotion to kick in here.    
</quote>    
    
I think `namespace-uri() = 'http://thing/'` do work because the way operands in    
a general comparison are treated is specified differently, and are not    
following the rules of value comparisons. More specifically, the expression    
`namespace-uri() = 'http://thing/'` works because when backwards compatibility    
is true, 4.b is invoked which reads: "If at least one of the two atomic values    
is an instance of xs:string, or if both atomic values are instances of    
xdt:untypedAtomic, then both atomic values are cast to the type xs:string."    
    
This leads me back to what actually is the issue(s). I claim this:    
    
* The specifications do not have any errors in this matter. The value  
comparison is as strict as it is intended to be, and there is no backwards  
compatibility problems with for example general comparisons.    
    
* Saxon have bugs in this area. For example, it does not flag  
`xs:string("example.org/") eq xs:anyURI("example.org/")` as    
a compile time error.    
    
   
                    ***  
  
A related issue:  
  
The expression `xs:float(3) eq xs:double(3)` should fail to compile due to no  
numeric promotion being specified. Instead it has the note paragraph in the  
fourth rule. This can be contrasted to operand treatment for function calls  
where numeric promotion is explicitly specified. However, section "B.2 Operator  
Mapping" specifies numeric promotion:   
   
<quote>   
A numeric operator may be validly applied to an operand of type AT if   
type-matches(ET, AT) is true where ET is any of the four numeric types. If the   
result type of an operator is listed as numeric, it means "the first type in   
the ordered list (xs:integer, xs:decimal, xs:float, xs:double) into which all   
operands can be converted by subtype substitution and type promotion."   
</quote>   
   
I wonder what that clause applies to; section "3.5.1 Value Comparisons" refers  
to "B2 Operator Mapping" although not explicitly mentioning the numeric  
promotion. I think it is intended to be for function calls, "For each numeric  
item in the atomic sequence that can be promoted to the expected atomic type  
using numeric promotion as described in B.1 Type Promotion, the promotion is  
done," but I would say it can easily be misinterpreted whether it applies for  
value comparisons as well.   
   
I suggest the editorial change that section "3.5.1 Value Comparisons" is   
updated to either explicitly refer to section B.1 Type Promotion(similar to how     
3.1.5 Function Calls do) /if/ numeric promotion is of interest, and if it is   
not, that there is an example that clarifies by showing an expression that   
fails to compile "xs:float(3) eq xs:double(3)"(error code XPTY0004).   
   
Another possible editorial is to remove the "global" numeric promotion clause  
in "B.2 Operator Mapping" and put it where it's needed, such that the "What  
does it apply to?"-problem goes away.  
  
  
Cheers,    
Frans    
    
1.    
http://sourceforge.net/mailarchive/message.php?msg_id=13149064

Received on Saturday, 1 October 2005 15:52:22 UTC