Re: Issues with xs:error in the XPath 3.0 and XDM 3.0

On 19 Apr 2014, at 05:26, Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote:

>
>
> A simple search in the XQuery and XPath Data Model (XDM) 3.0 W3C
> Recommendation for the string "xs:error", returns 0 results.

You are right, this area is not well covered by the XDM specification; you
have to treat xs:error as being included implicitly by virtue of the fact that
all XSD built-in types are included.
>
> In the XDM 3.0 Recommendation there are three type diagrams:
>
> The type xs:error is absent in any of these charts.

It does say that the diagrams are incomplete, in particular it only includes
types defined as part of a hierarchy.
>
> This raises a number of questions:
>
>
>  4. Where in the type hierarchy is the type xs:error located --
> which, if any is its immediate base type?

XDM states that the type system is not a hierarchy but a lattice. xs:error is
the "bottom" type in this lattice, it is a subtype of every other type.
>
>  5. Section "2.5.7 xs:error" of the XPath 3.0 Recommendation
> describes the xs:error type. This is different from the formal
> definition of xs:error in the XML Schema 1.1 Recommendation (Section
> 3.16.7.3 http://www.w3.org/TR/xmlschema11-1/#xsd-error). Which of the
> two definitions of xs:error (in XPath 3.0 or in XSD 1.1) is the
> normative one and which is the redundant one?

XPath doesn't contain anything resembling a definition of this type; it merely
refers to it by name. The definition is in XSD 1.1.
>
>  6. Section "2.5.7 xs:error" of the XPath 3.0 Recommendation states
> that "A cast to xs:error raises an error or returns the empty
> sequence."  In what cases is an error raised and in what cases is the
> empty sequence returned?  What are examples of the two different
> situations? In which document should we find the answer to this
> question?

Casting is described normatively in F+O. xs:error is a union type (a union
with no member types) and the semantics are therefore defined by 18.3.5
Casting to union types. It's a consequence of the general rules for casting to
a union type that casting to xs:error throws an error if the argument is a
single item, and returns an empty sequence if the argument is an empty
sequence.
>

By way of background to this, it was realised at a fairly late stage that if
all built-in types from XSD 1.1 were to be supported in XPath 3.0, then this
included xs:error and t would be a good idea to say something about how
xs:error should behave; the only alternative was to specifically exclude it.
Everything the specs say about xs:error is a consequence of the fact that (a)
xs:error is a built-in type, and (b) it is defined as a union type with no
member types. There is no special treatment of xs:error, merely explanations
of the consequences of its existence and the way it is defined.

Michael Kay
Saxonica