[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: [xsl] Issues with xs:error in the XPath 3.0 and XDM 3.0 Recommendations.
Subject: Re: [xsl] Issues with xs:error in the XPath 3.0 and XDM 3.0 Recommendations. From: Michael Kay <mike@xxxxxxxxxxxx> Date: Sun, 20 Apr 2014 00:42:22 +0100 |
A QName used in this syntactic context is not interpreted as a type; it is interpreted as an Axis step child::xs:error. Unless the context item has a child element called xs:error, the expression returns an empty sequence. To look for uses of xs:error you have to look for expressions where a QName is interpreted as a type, for example if (X instance of xs:error) -- always false X cast as xs:error -- always an error unless X is empty One way one might construct a scenario where xs:error is possibly useful is via function-lookup(). Suppose I am passed a type local name (e.g. "int" or "string") as a parameter, then I can cast to that type by doing function-lookup(QName(XSD_NAMESPACE, $type), 1)($input) and if I want the cast to always fail, then I can supply $type := "error". Michael Kay Saxonica On 20 Apr 2014, at 00:03, Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote: > I apologize, but I am still curious to see a legal (and if possible > meaningful) XPath expression that involves xs:error. > > I tried this in BaseX and it works, but it seems totally wrong to me > -- returning a type! And from the explanations about xs:error, it > would be an error to use it as a constructor. > > let $v := 3 > return > if($v eq 2) then xs:error > else $v > > > > On Sat, Apr 19, 2014 at 3:55 PM, Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote: >> On Sat, Apr 19, 2014 at 3:45 PM, Michael Kay <mike@xxxxxxxxxxxx> wrote: >>> 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. >> >> Thank you, Michael, >> >> Is it then a logical conclusion to try to avoid (never use) the >> xs:error type in XPath? >> >> >> Cheers, >> Dimitre Novatchev > > > > -- > Cheers, > Dimitre Novatchev > --------------------------------------- > Truly great madness cannot be achieved without significant intelligence. > --------------------------------------- > To invent, you need a good imagination and a pile of junk > ------------------------------------- > Never fight an inanimate object > ------------------------------------- > To avoid situations in which you might make mistakes may be the > biggest mistake of all > ------------------------------------ > Quality means doing it right when no one is looking. > ------------------------------------- > You've achieved success in your field when you don't know whether what > you're doing is work or play > ------------------------------------- > To achieve the impossible dream, try going to sleep. > ------------------------------------- > Facts do not cease to exist because they are ignored. > ------------------------------------- > Typing monkeys will write all Shakespeare's works in 200yrs.Will they > write all patents, too? :) > ------------------------------------- > I finally figured out the only reason to be alive is to enjoy it.
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Issues with xs:error in t, Graydon | Thread | Re: [xsl] Issues with xs:error in t, Dimitre Novatchev |
Re: [xsl] Issues with xs:error in t, Graydon | Date | Re: [xsl] Issues with xs:error in t, Dimitre Novatchev |
Month |