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

It is probably too late now to try to make this more useful (as with following the suggestion in the spec that this is another way of raising errors):  Since xs:error is a subtype of every other type, it seems to make sense that type promotion from any type could be allowed, which suggests a special type of type errors:

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.

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.

> 
> 2. Do we have tests for this?  

Yes, in xs/error.xml. Quite a few, but the challenged cases are not in there.

> The same implementation does raise an error
> for this query:
> 
> let $x as xs:error := 1
> return $x
> 
> However, the error says "An empty sequence is the only allowed value for
> the value of variable $x", which seems just plain wrong.

Yes, I would assume this message to be incorrect. But here, other than the previous example, the compiler can assure that the type error is always thrown, so it can statically raise the error. Consider:

let $x as xs:error := xs:error('')
return 1

Or:

let $x as xs:error := xs:error('')
return if(@a) then @a else $x

of which the latter is the intended use-case (though it would be slightly more useful if you could put a message for the error inside constructor, similar to fn:error).

I would argue that an optimizing compiler can remove the $x declaration if it can assess that it is never used (late binding).

> 
> 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
> };

Good point. But I don't think that a function declaration is similar to a variable declaration, in the sense that it does not lead to variable binding unless called. Similarly, the following should be compilable, imo:

declare function local:f() {
   let $e as xs:error := error('')
   return $e
}

Disallowing this is like disallowing a method in C# or Java to return an Exception object, or if it raises an exception to fail the whole program...

> 
> In the query of XPath / XQuery per se, is there ever a need to allow xs:error
> as a sequence type?  If so, where?  It's not something I've ever done. Would
> it be better to simply forbid xs:error as a sequence type?  But it may be too
> late for that.  The associated error message claims that the reason for
> allowing this is so that it can be used in the SequenceType syntax to raise
> errors. Can someone explain that to me?  My memory fails me here ...

I think we have to have it simply because it exists in XML Schema, and we must be able to map types to it (though there is nothing to map because there is no value space...).

I am just as much confused by you about the sentence in the spec suggesting it is an alternative to raise errors. Perhaps the original intend was *not* to forbid binding, and that that sentence was meant to be understood something like "raise a dynamic type error if you encounter xs:error". 

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

A quick search turned up:

* several occurrences where xs:error is written and xf:error is meant (which is from an old Draft of XQuery 1.0)
* Mukul Gandhi wrote the following, and shows several applicable examples[1]:
" or the type on xs:alternative could be xs:error (this is a new schema type defined in XSD 1.1 spec, and is particularly useful with XSD type alternatives. The schema type xs:error has an empty lexical and value space, and any XML element or attribute which has this type, will always be invalid)."
* a schema that uses xs:error in the wild at StackOverflow, see answer by MSMcQ [2]
* a publicly reported Zorba bug on xs:error [3]
* our previous discussion in Bug#20634 [4]
* interesting: in this report on Saxon, Michael Kay says that node() is a subtype of xs:error, but in our XPath 3.1 text we say it is a subtype of atomic values. I think that XSD 1.1 says it is a subtype of every other type [5]
* and a user asking in 2013 about explicitly invalid type, MSMcQ answering [6]

Conclusion: I couldn't find anything serious related to XQuery, XPath or XSLT "in the wild" other than people asking questions about it, except for XSD 1.1, where it seems to be used more than just occasionally. 

Note: in XQuery 1.0 we wrote:

"However, the fn:error() function must not be evaluated during the static analysis phase."

It seems to make sense to apply the same rule to variables / arguments / functions with return values typed as xs:error.

[1] http://mukulgandhi.blogspot.nl/2009/11/xsd-11-conditional-type-assignment-cta.html
[2] http://stackoverflow.com/questions/13653995/dynamic-enumeration-restriction-using-xsd-1-1
[3] https://bugs.launchpad.net/zorba/+bug/1170470
[4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20634
[5] https://saxonica.plan.io/issues/2032 
[6] http://stackoverflow.com/questions/14481166/is-it-possible-for-xml-to-have-valid-schema-but-no-xml-document

Received on Tuesday, 29 September 2015 00:37:07 UTC