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

[Bug 22552] New: [XP3.0] subtype(A, B) and xs:error

From: <bugzilla@jessica.w3.org>
Date: Wed, 03 Jul 2013 08:30:37 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-22552-523@http.www.w3.org/Bugs/Public/>

            Bug ID: 22552
           Summary: [XP3.0] subtype(A, B) and xs:error
    Classification: Unclassified
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XPath 3.0
          Assignee: jonathan.robie@gmail.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

Section 2.5.7 says that xs:error? and xs:error+ are "identical" to
empty-sequence(). But the table in gives different outcomes for
subtype(xs:error?, X) and subtype(empty-sequence(), X). For example, it says
that subtype(xs:error?, empty-sequence()) is false, while
subtype(empty-sequence(), empty-sequence()) is true.

I think the answer to this problem is to define another row and column in the
table labelled xs:error, and to state in an annotation to the table that
xs:error+ is treated like xs:error, while xs:error? and xs:error* are treated
like empty-sequence(). The entries in the new row and column are

subtype(xs:error, X) all rows true
subtype(X, xs:error) all rows false except subtype(xs:error, xs:error).

The existing exception in one cell of the table can then be removed.

Incidentally, we have now established that XSD 1.1 does not define a valid XML
representation for union types with no members, so in practice we can treat
xs:error as being the only such type.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 3 July 2013 08:30:38 UTC

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