- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 26 Aug 2009 10:20:07 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7424 --- Comment #4 from Oliver Hallam <oliver@cbcl.co.uk> 2009-08-26 10:20:07 --- 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. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 26 August 2009 10:20:17 UTC