RE: ACTION A-617-01 Jonathan to bring discussion of bug 29119 to the mailing list

> 
> I don’t think we “disallow" it, any more than we disallow division by zero.
> 
> If you’re referring to the sentence "A variable binding with a type declaration
> xs:error always raises a type error.” then my interpretation of that sentence
> is that it’s simply a redundant statement of fact:
> 
> (A) (3.11.1) At run time, if the value bound to the variable does not match
> the declared type according to the rules for SequenceType matching, a type
> error is raised [err:XPTY0004].
> (B) no value matches the type xs:error
> (C) Therefore, if the declared type is xs:error, a type error is raised, whatever
> the value.
> 

Sorry if I made myself unclear, but I thought the discussion was brought to the list to have another look at it. I'm ok with the current spirit of the spec that it should raise a type error, but the sentence with "always" juxtaposes elsewhere in the spec the way type errors are described, which is (colloquially): they are thrown when the processor sees fit. I.e., they are not thrown always and the following may raise with one processor but may succeed with another, and both treatments are allowed:

let $e as xs:error := xs:error(())   (: or xs:error(1) :)
return 2

(which in essence makes declaring something as xs:error utterly useless)

Received on Tuesday, 29 September 2015 12:20:17 UTC