This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Since a range expression does not exist in XPath 1.0, the compatibility mode should nor affect the normalization. However, the specification says (3.3.1) Each of the operands of the to operator is converted as though it was an argument of a function with the expected parameter type xs:integer?. Would it not be better to normalize the parameters as when compatibility mode is false?
I think that the function conversion rules for an argument declared as xs:integer? are exactly the same whether 1.0 compatibility mode is on or off. So I don't think I understand where the problem lies.
with XPath 2.0 conversion rules, 1 to (2,3) is a cardinality error. With XPath 1.0 rules, 1 to (2,3) is (1,2).
Ah right, I missed that. But I can't see why you would want to use different rules from those for function calling. Surely it's easier to implement the same rules everywhere?
This seems to be the only place (apart from function calls) in the XPath specification that references the function conversion rules. XSLT 2.0 uses the following as a definition for function conversion rules: [Definition: Except where otherwise indicated, the actual value of an expression is converted to the required type using the function conversion rules. These are the rules defined in [XPath 2.0] for converting the supplied argument of a function call to the required type of that argument, as defined in the function signature. The relevant rules are those that apply when XPath 1.0 compatibility mode is set to false.] which I would be in favour of using in this case. I would argue that the backwards compatibility mode should affect as little of the language as possible, and so I personally would try to limit its effects to normalization of function calls, arithmetic operators and general comparison operators, and the explicit evaluation order of logical expressions. Since the range expression is new to XPath 2.0 its behaviour does not need to be affected by compatibility mode and I would argue that it is simpler (which is surely a more important goal than ease of implementation) not to change it. It really comes down to whether the range expression is just considered syntactic sugar for a function call, or is a fundamentally a different expression (as with all other operators which have different conversion rules). Another case when the rules differ is for xs:untypedAtomic arguments which with compatibility mode set to false is allowed, but with compatibility mode set to true raises an error. Since it does not affect valid XPath 1.0 expressions (which is after all the only purpose of the compatibility mode) then I will concede that this distinction is trivial at best, and I can live with the current wording. Indeed I have probably written far more than this problem deserves.
If I weren't the owner of an implementation, I would argue: (a) your case would have merit if we were designing the spec now (b) however, the fact that a change is an improvement is not a good enough argument to make the change retrospectively. As it is, I *am* an implementor, and I have discovered that my implementation works the way you would like the spec to say it should. In that situation, all I can say is that I am torn, and will accept the views of the WG on the matter.
Having speculated earlier on ease of implementation, I might add that in Saxon, going one way or the other is a matter of changing "true" to "false" in a single method call.
The WG agrees with the characterization of the problem given by Mike Kay in Comment #5. At this point, we do not believe that the effort involved in changing the specification is justified for the very minor improvement that would result.
I have created a test case backwards074 to test this situation in the XSLT 2.0 test suite.