This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2324 - Value/General comparisons: type promotion for xs:anyURI/numeric
Summary: Value/General comparisons: type promotion for xs:anyURI/numeric
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 2.0 (show other bugs)
Version: Candidate Recommendation
Hardware: Other Linux
: P2 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2005-10-01 15:52 UTC by Frans Englich
Modified: 2006-03-11 15:42 UTC (History)
0 users

See Also:


Description Frans Englich 2005-10-01 15:52:10 UTC
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("") eq xs:anyURI("")    
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:    
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.    
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("") eq xs:anyURI("")` 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:   
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."   
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.  
Comment 1 Liam R E Quin 2005-10-01 16:45:29 UTC
Frans, please note that the comment period for the Last Call Working Drafts
ended quite some time ago.

The usual next stage after a Last Call Working Draft is
W3C Candidate Recommendation (or sometimes another Working Draft and
Last Call, if there were too many changes).  In either case, the next
version will have a request for comments.

I don't want to discourage you from submitting comments: public review
has made a huge difference to the specifications!  But the Working Group
won't have a chance to look at them until after the next versions of the
documents have been published, so you may want to wait for that and then
see if your comments still apply.

Liam (not writing on behalf of the Working Group)
Comment 2 Frans Englich 2005-10-01 16:56:14 UTC
If a submitted comment of mine gets considered or not at a specific time, is  
for me of less interest. What I find important is that a comment that (may) be  
of importance gets recorded and at some point gets considered. Phrased  
differently, it's of course ok if a comment of mine does not get a response at 
some specific point, since I namely comment outside the comment period. So, I'm 
aware of the consequences of my "rule breaking" :) 
It can also be said that it was Michael Kay, who is a WG member, that actually  
suggested the bug report: "I think it's a bug in the spec. Can you raise it, or  
shall I?"(see the referenced thread in comment #1).  
But I understand your concern and appreciate it. 
Comment 3 Liam R E Quin 2005-10-01 17:15:39 UTC
OK, thanks for replying, Frans.  My main concern was (and is) just that you
understood where we are in the process; your comments will not get lost!

Comment 4 Michael Kay 2005-10-01 18:36:44 UTC
Firstly, Frans, I'm confident that it was the intention of the WG that both
numeric and URI promotion should apply to the operands of value comparison
operators. In fact, the primary motivation for the introduction of URI promotion
was to allow URIs to be tested for equality against string literals. (This was
after rejecting alternatives such as the introduction of a special URI literal.)

I'm inclined to agree with you that the specs don't say this very clearly,
though others may differ. Section B.1 does say:

Type promotion is used in evaluating function calls (see 3.1.5 Function Calls)
and operators that accept numeric or string operands

I think the problems are (a) B.1 doesn't say exactly how or when type promotion
is used in evaluating these operators, and (b) although B.1 says that type
promotion is used, section 3.5.1 (Value Comparisons) appears to differ, as it
gives a detailed sequence of steps for evaluating a value comparison that
doesn't include any reference to section B.1 or any mention of type promotion.

I'll stick my neck out and say that I'm pretty confident the WG will respond to
this issue by confirming that type promotion has always been intended to apply
to value comparisons.

Thanks for raising it.

Michael Kay (personal response)
Comment 5 Frans Englich 2005-10-01 19:42:01 UTC
I don't doubt your knowledge on the history, direction and design philosophy of 
XPath 2.0. Unfortunately, my background material is what I think I read and 
what I otherwise also thinks. After considering your saxon-help post, I did 
manage to get it all together without compatibility problems, so I decided to 
take a shot in a different direction. Always good with different views. 
I also think this will be resolved as an editorial fix unless, of course, 
someone sticks their head out and says "What? I thought we agreed to not have 
any value comparisons?", or similar. 
Comment 6 Michael Kay 2005-11-21 17:04:13 UTC
I have changed the "Version" field so this shows up as a comment on the
Candidate Recommendation.
Comment 7 Frans Englich 2006-01-07 19:45:29 UTC
Continuing the discussion of this editorial issue:      
 Report #2545 was resolved by explicitly mention treatment of xs:anyURI. Step 3     
and 4 in the function conversion rules(3.1.5 Function Calls) explicitly   
mention promotion rules for numeric types and xs:anyURI.     
Perhaps the fix for this report is to copy step 3 and 4 from the function    
conversion rules to the steps in 3.5.1 Value Comparisons(becoming step 5     
and 6). To me it looks like such a fix would be in the same style as how other  
similar cases are worded. I also believe it would solve this issue; clarify  
whether numeric/xs:anyURI promotion is invoked for value comparison.  
However, by principle I question this way of fixing errors, it feels like  
patching the spec in a spaghetti-code like way. From my impression there have 
been a number of reports/discussions concerning type handling/operand rules, 
and it wouldn't surprise me if the cause partly is that texts are halfly 
duplicated in many places. 
For example, from what I can tell it is effectively the function conversion  
rules that are invoked for value comparisons, with the only exception of how  
the parameter type is determined. Could that be expressed in some concise way,  
such that one could reuse the text function conversion rules? 
I think such things means a lot in terms of learnability("Oh, the func rules 
are kicked in here, I know already those"), implementing(it is a complex task 
to determine whether two sections means the same; modularization in the spec 
can affect modularization in implementation), and how daunting impression the 
spec gives. 
Comment 8 Don Chamberlin 2006-03-08 00:21:34 UTC
On 07 March 2006 the Query and XSLT working groups considered your comment and agreed that some clarifications would be helpful. The groups voted to adopt the text shown below. We believe that this text addresses the issues raised by your comment. If you agree, please change the status of this Bugzilla entry to "Closed" (the working groups will automatically close this entry if we do not hear from you within two weeks). Thanks for calling our attention to this issue!
Don Chamberlin (for the Query and XSLT working groups)

Proposed changes to XPath/XQuery document:

1. In Section 3.5.1 (Value Comparisons), change the paragraph following 
rules 1-4 as follows: 

Next, if possible, the two operands are converted to their least common 
type by a combination of [type promotion] and [subtype substitution]. For 
example, if the operands are of type hatsize (derived from xs:integer) and 
shoesize (derived from xs:float), their least common type is xs:float. 

Finally, if the types of the operands are a valid combination for the 
given operator, the operator is applied to the operands. ... (continue as 
in current draft) 

2. In Appendix B.2 (Operator Mapping), change the third paragraph as 

If an operator in the operator mapping tables expects an operand of type 
ET, that operator can be applied to an operand of type AT if type AT can 
be converted to type ET by a combination of [type promotion] and [subtype 
substitution]. For example, ... (continue as in current draft) 

3. In Appendix B.2 (Operator Mapping), change the fifth paragraph 
(immediately following the small table of four numeric operators) as 

A numeric operator may be validly applied to an operand of type AT if type 
AT can be converted to any of the four numeric types by a combination of 
[type promotion] and [subtype substitution]. If the result type of an 
operator is listed as numeric, ... (continue as in current draft) 

(Editor's note: [type promotion] and [subtype substitution] are defined 
terms that contain links to their definitions.) 
Comment 9 Frans Englich 2006-03-11 15:42:15 UTC
Yes, I think the changes are fine, and therefore close this report. Thanks for the detailed description of the changes.