W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2012

[Bug 16948] New: [FO30] number() when the context item is a list

From: <bugzilla@jessica.w3.org>
Date: Sun, 06 May 2012 20:23:39 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-16948-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16948

           Summary: [FO30] number() when the context item is a list
           Product: XPath / XQuery / XSLT
           Version: Proposed Edited Recommendation
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators 3.0
        AssignedTo: mike@saxonica.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


Also applies to the XPath 2.0 functions and operators spec.

It's not clear what happens when number() is called with no arguments, and the
context item is a node whose typed value is a list containing more than one
atomic value. The spec makes two conflicting statements: on the one hand, it
says that number() is equivalent to number(.), in which case a type failure
would occur because atomization delivers a value that does not match the
required type of xs:anyAtomicType?. On the other hand, it says that if
conversion of the context item to a double fails, the function returns NaN.

I think the preferred solution is that number() behaves exactly like number(.),
which means there is a possibility of a type error.

Other functions whose argument defaults to the context item do not seem to have
the same problem. Some of them do not atomize (for example name(), nilled());
others explicitly work on the string value of the node (normalize-space(),
string-length()); while data() allows the result of atomizing to be a sequence.

-- 
Configure bugmail: https://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 Sunday, 6 May 2012 20:23:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:38 UTC