This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There are a large number of functions specified of the form like, for example, (http://www.w3.org/TR/xquery-operators/#func-years-from-duration) fn:years-from-duration($arg as xs:duration?) as xs:integer? which only return the empty sequence if the argument is the empty sequence. For static type checking purposes, it is often convenient to be able to specify that the type of an expression not contain the empty sequence, but this becomes difficult to reason about when so many functions may be returning empty sequence. It would be helpful if there were also function specifications of the form fn:years-from-duration($arg as xs:duration) as xs:integer with the additional static rule of choosing the most specific form (since this is obviously overloading the function name). There may be other ways of addressing this issue.
Personal (and interim) response: (a) extra rules for static type checking belong in the formal semantics document, not in the F+O specification. (b) I think we relaxed the static typing rules sufficiently to allow products to make type inferences beyond those that we list in the FS specification. There's vast scope for this, and I think that encoding everything that one can deduce about the return type within the signature would not be possible or helpful. It's true that there are some common patterns - such as "if arg0 is empty then result is empty" or "result is of the same type as arg0", but there are also many more subtle variations, especially if your static analysis is interested in static properties other than the type, which seems rather likely in a real product, but is well outside the scope of the specification.
#1 sounds sensible to me. I believe such inferences can be implemented as static typing extensions, see 5.2.3.1 Static Typing Extensions in the XQuery spec.
Recategorized as 1.1 feature request
The WG considered this bug 2009-02-24 and agreed with the gist of comment #1, that static extensions can take care of this issue. The bug is therefore being closed with no action.
Since we informed the originator that this was being closed with no action and there has been no push-back, I am marking this closed. Please feel free to reopen it if you are not satisfied with this outcome.