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

> 
> if(@a > 5) then xs:error(@a) else @a
> 
> Which could be reported (probably in another world, I know) by processors as: "XPTY0004: attribute type with value 8 is considered of invalid type", which may more closely match the original meaning and use-cases in XSD with xs:alternative.

I’m not sure what you are getting at here. This one seems perfectly clear to me: if the condition (@a > 5) is true, the expression raises a dynamic error FORG0001. Why is this case a problem? 

> 
> See below for some other thoughts:
> 
> 
>> 
>> 1. How does this interact with Errors and Optimization? I was surprised to find
>> at least one popular implementation that happily returns "1" as the result of
>> this query:
>> 
>> let $x as xs:error := ()
>> return 1
> 
> I think this assignment is not allowed, because xs:error is only a supertype of itself, and promotion is not supported. But I also think that it should not (necessarily) throw an error. It is a type error, and an optimizing compiler can compile $x away: it is never called.

The possible outcomes here are : (1) the processor can optimize the variable away and return 1, or (2) it can raise a type error because () is not a valid instance of xs:error; it can raise this type error either (2a) statically or (2b) dynamically. 

This case is no different from writing

let $x as xs:integer := “London” return 1

so I fail to see why we find it troublesome.

(Note that a processor that does static type checking and that optimizes the variable away statically might do these steps in either order, with different outcomes…)

> 
>> 
>> 3. The text is not very precise.  Does it apply to variable bindings established
>> by passing parameters to functions?
>> 
>> What should an implementation do with a function declaration like this,
>> assuming it is not called?
>> 
>> declare function local:f($e as xs:error) as xs:error {
>>  $e
>> };
> 

This is a legal function declaration, but any attempt to call the function will result in a type error.

>> 
>> In the query of XPath / XQuery per se, is there ever a need to allow xs:error
>> as a sequence type? 

We don’t allow it because there is a use case, we allow it because there is no reason not to. We don’t disallow multiplication by zero just because we can’t see why anyone would want to do it. Orthogonality drives the design here: no unnecessary restrictions.


> 
>> 
>> Are there queries in the wild that do this?  If so, why?
>> 
> 

Not relevant.

Received on Tuesday, 29 September 2015 10:10:32 UTC