W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2009

[Bug 7424] [XPath 2.0] XPath 1.0 compatibility mode with range expressions.

From: <bugzilla@wiggum.w3.org>
Date: Wed, 26 Aug 2009 10:20:07 +0000
To: public-qt-comments@w3.org
Message-Id: <E1MgFbr-0002Dw-PF@wiggum.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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:40 UTC