This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
On reflection, I don't think that prohibiting xs:error would save any work for implementors, because the behaviour is exactly the same as a user-defined union type with no member types, and implementations need to support that anyway.
XQuery Formal Semantics 1.0 describes the 'none' type as: "... none is ... equivalent to a union type with no member types." Perhaps xs:error is the same type as, or at least very closely related to, 'none'.
Some further observations: (a) we say in 4.11: [Definition: A schema import imports the element declarations, attribute declarations, and type definitions from a schema into the in-scope schema definitions. For each user-defined generalized atomic type in the schema, schema import also adds a corresponding constructor function. ]. So it seems that at least in the case where there is an "import schema" declaration, we already import the type xs:error (because it is present in every schema), and we also add a corresponding constructor function xs:error() whose behaviour is rather similar to fn:error(). If there is no "import schema" declaration, the status quo is less clear. (b) since xs:error is an empty union, and since a user-defined XSD 1.1 schema can include an empty union type, there are no new semantic problems - there is no doubt that a query can import an empty union type and that its semantics must be well-defined, the only question is whether it imports the particular empty union type called xs:error.
Here is a concrete proposal against the spec which officially allows xs:error (only substantive changes are shown - notes can also be added at various places in the specification to clarify some aspects). XDM 3.0 ======= 2.7.2 Predefined Types - Add xs:error to the list of additional types and to the list of types superseded by XML Schema 1.1. - "five additional types" -> make it six - Add the following paragraph: xs:error The datatype xs:error is a union type with no member types. Its base type is xs:anySimpleType. It cannot exist as a dynamic type as its value space and lexical space are empty. XQuery 3.0 ========== 2.5.1 Predefined Schema Types - Add to the list summarizing schema types specified in the XDM: [Definition: xs:error is a simple type with no value space. It can be used in the SequenceType syntax to raise errors.] Add paragraph 2.5.7 xs:error The type xs:error has an empty value space and it never appears as a dynamic type or as the content type of a dynamic element or attribute type. It offers an alternative way of raising errors, in addition to fn:error. Cast to xs:error raises an error or returns the empty sequence. Promotion to xs:error is not possible. xs:error (as well as xs:error+) does not match any value, is a subtype of all simple types, and a supertype only of itself. xs:error? and xs:error* are identical to empty-sequence(). A variable binding with a type declaration xs:error always raises a type error. Calling a function in the signature of which xs:error appears always raises a type error.
In today's telcon, the Working Group accepted comment #4 as the resolution of this bug.