W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2013

[Bug 21766] New: [F+O 3.0] Error code on casting to a union type

From: <bugzilla@jessica.w3.org>
Date: Mon, 22 Apr 2013 13:57:32 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-21766-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21766

            Bug ID: 21766
           Summary: [F+O 3.0] Error code on casting to a union type
    Classification: Unclassified
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 3 & XPath 3 Test Suite
          Assignee: oneil@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

I believe a number of the new xs:error tests are returning XPTY0004 when
FORG0001 would be more appropriate. However, the rules are not completely
clear, so I'm raising this as a spec bug.

The rules that apply are in F+O 18.3.5. This states that the supplied value
must be either a string, or an instance of a member type of the union, or
castable to a member type of the union. If it is a string, as in test
xs-error-010, then it seems clear that the appropriate error is FORG0001 (the
test is written to expect XPTY0004). If it is any type other than string, then
none of the three conditions applies, and the spec isn't clear what the error
code should be; one could argue for XPTY0004 in this case, by analogy with the
rule for casting to atomic types ("If casting is attempted from an ST to a TT
for which casting is not supported, as defined in the table below, a type error
is raised [err:XPTY0004]XP30." in 18.1)

However, this is a little problematic with regard to the third rule. ("A value
that is castable to one or more of the atomic types in the transitive
membership of the union type (in the sense that the castable as operator
returns true)."). This rule depends on the source value, not only on its type,
so a type error seems inappropriate.

It seems unreasonable to require implementations to distinguish the case where
no instance of the type of the supplied value could be cast to the union type
from the case where the particular instance cannot be cast to the union type,
solely in order to raise different error codes for the two cases. Therefore I
propose that any failure to cast to a union type (because none of the three
rules is satisfied) should result in FORG0001.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 22 April 2013 13:57:41 UTC

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