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

> ACTION A-617-01 Jonathan to bring discussion of bug 29119 to the mailing
> list.

First off, please note Comment #4:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29119#c4

I suspect we should simply eliminate the sentence from the XPath spec, leaving it in XQuery.

However, in the name of due diligence, I also think I should raise one or two cans of worms.

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

2. Do we have tests for this?  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.

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

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 ...

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

Jonathan