This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4939 - [FO] Specify both "fn:f(a as t?) as r?" and "fn:f(a as t) as r"
Summary: [FO] Specify both "fn:f(a as t?) as r?" and "fn:f(a as t) as r"
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.0 (show other bugs)
Version: Recommendation
Hardware: All All
: P4 enhancement
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2007-08-09 16:34 UTC by Ben Wagner
Modified: 2009-10-12 22:28 UTC (History)
1 user (show)

See Also:


Description Ben Wagner 2007-08-09 16:34:39 UTC
There are a large number of functions specified of the form like, for example, (

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.
Comment 1 Michael Kay 2007-08-09 22:11:14 UTC
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.
Comment 2 Frans Englich 2007-09-11 14:37:08 UTC
#1 sounds sensible to me.

I believe such inferences can be implemented as static typing extensions, see Static Typing Extensions in the XQuery spec.
Comment 3 Jim Melton 2008-03-14 20:41:17 UTC
Recategorized as 1.1 feature request
Comment 4 Mary Holstege 2009-02-24 21:39:09 UTC
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.
Comment 5 Michael Kay 2009-10-12 22:28:48 UTC
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.