Re: [xsl] Issues with xs:error in the XPath 3.0 and XDM 3.0 Recommendations.

[Michael Kay <mike@xxxxxxxxxxxx>]

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.