xsl-list
[Top] [All Lists]

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

2014-04-19 18:42:42
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(_at_)gmail(_dot_)com> 
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(_at_)gmail(_dot_)com> wrote:
On Sat, Apr 19, 2014 at 3:45 PM, Michael Kay <mike(_at_)saxonica(_dot_)com> 
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.

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--