[Bug 20634] New: [XP 3.0] The XSD 1.1 type xs:error

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20634

            Bug ID: 20634
           Summary: [XP 3.0] The XSD 1.1 type xs:error
    Classification: Unclassified
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          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

XSD 1.1 introduces a new type called xs:error. We need to say something about
it.

xs:error a type with an empty value space. As such, we will never encounter
instances of it at run time, either as atomic values or as type-annotated
nodes. But as things stand, it's defined to be present in every schema, and as
such it can be used in expressions like

$x treat as xs:error

The definition of xs:error is as a union type with no member types. It
therefore falls into our definition of a "pure union type" and therefore a
"generalized atomic type". There is therefore a constructor function
xs:error($in) (which always fails FORG0001, except when $in is the empty
sequence), and we can use the type name in a SequenceType.

Generally the semantics seem to fall out quite naturally from the definition,
and we don't need to say very much, but we should mention that it's allowed and
have some test cases.

One thing that might need a little more care is the type:type subtyping rules.
According to our rules, xs:error will be a subtype of every union type. I think
that in XSD xs:error is also substitutable for every atomic type, but I'm
having trouble seeing where it says this.

An alternative approach would be to say that the type xs:error is NOT available
for use in queries. This is an unnecessary and artificial restriction, but it
might save implementors a bit of work, it would require fewer tests, and few
users would grieve over it. But even if this is what we say, we still need to
say something.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 10 January 2013 14:17:23 UTC