This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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)
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. Cheers, Frans
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! Liam
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)
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. Cheers, Frans
I have changed the "Version" field so this shows up as a comment on the Candidate Recommendation.
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. Cheers, Frans
Frans, 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! Regards, 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 follows: 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 follows: 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.)
Yes, I think the changes are fine, and therefore close this report. Thanks for the detailed description of the changes. Regards, Frans