Subject: Re: [xsl] Issues with xs:error in the XPath 3.0 and XDM 3.0 Recommendations. From: Michael Kay <mike@xxxxxxxxxxxx> Date: Sat, 19 Apr 2014 23:45:32 +0100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Issues with xs:error in the X, Dimitre Novatchev | Thread | Re: [xsl] Issues with xs:error in t, Dimitre Novatchev |
[xsl] What is new in the XPath Data, Dimitre Novatchev | Date | Re: [xsl] Issues with xs:error in t, Dimitre Novatchev |
Month |