This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
If, during type checking, it can be determined that fn:data may be applied to a node type which does not have a typed value, which of the following (if any) should occur? a) err:XPTY0004 be raised at type check time. b) err:FOTY0012 be raised at type check time. c) No errors raised at type check time, but err:FOTY0012 be raised during evaluation. If the correct behaviour is (c), what should be the static return type of fn:data?
Tim, As I understand that case can only occur when the type is a complex type with complex content which is not mixed. I think in that case there is no inference rule for the 'data on' judgment, and the normal static typing error will be raised, i.e., case (a). If I am not wrong, this comment does not require any change to our document, is that also your understanding? Thanks, - Jerome
Thanks. The only problem I have with that solution is that it isn't obvious from the signature of fn:data as to why a type checking error is being thrown, since the function accepts item()*. Were I an end user (who hadn't spends ages pouring over the Formal Semantics!) I might be a little confused and think that the implementation was at fault. Similar arguments apply to fn:boolean which also accepts item()*, but may throw err:FORG0006 at run time for some inputs.
I think part of the reason for this is that the function signature syntax and the sequence type syntax do not allow to precisely describe the typing behavior. This is why we use inference rules in those cases. I agree could be confusing for a reader, but I'm not sure what to do about it. Would you have any suggestion to improve this? Thanks, - Jerome
Tim, The XSLT and XML Query working groups have reviewed this bug, and decided to reclassify it as editorial in order to give you a chance to suggest possible clarifications on this. Thanks, - Jerome
Personally, I think I'd just go with raising no errors at type check time, and raising err:FOTY0012 during evaluation. At least that way it is consistent with non-static typing implementations.
Tim, I am suspecting the change you suggest here is more than editorial. I am reclassifying it back to 'normal' so it is considered by the working group. Thanks, - Jerome
OK thanks. Here's an example of why doing anything other raising an error at runtime is a "bad thing". declare function local:if-data($test as item()*, $data as item()*) { if (fn:boolean($test)) return fn:data($data); else return (); }; This wouldn't pass static type checking because of the differences between the declared argument types of fn:boolean and fn:data, yet at first glance (or without static type checking) is fine.
[14:06] scribe: Topic: Issue 4072 [14:07] cferris: http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0103.html [14:08] cferris: relates to http://www.w3.org/Bugs/Public/show_bug.cgi?id=4072 [14:08] scribe: Daniel: This proposal address the remainder of the existing Issue. [14:09] scribe: General text on policy references weren't relevant to assertion design. Recognized however, best practice exists for attachments. Semantics don't have dependency on attachment mechanism used. [14:09] *** ArnaudM has signed off IRC (Quit: CGI:IRC (EOF)). [14:10] scribe: Rewrote Section 4.1 and added Best Practice. [14:10] fhirsch3: q+ [14:11] * Zakim sees fhirsch on the speaker queue [14:12] fhirsch3: q- [14:12] * Zakim sees no one on the speaker queue [14:13] scribe: RESOLUTION: Issue 4072 as revised proposal in http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0103.html [14:14] cferris: rrsagent, where am i? [14:14] RRSAgent: See http://www.w3.org/2007/03/14-ws-policy-irc#T18-14-48
OOPS... disregard previous entry... misapplied resolution to the wrong bug id
(personal response) Re Comment #0: If the Static Typing Feature is in effect, and static analysis of a call to fn:data() finds that the static type of the argument prevents the inference of a static type for the call, then I believe a type error [err:XPTY0004] is raised. [XQuery 2.2.3.1 plus FS 7.2.6] Whether or not the Static Typing Feature is in effect, if static analysis can determine that, if evaluated, the fn:data() call would necessarily be applied to a node without a typed value, then the implementation may raise err:FOTY0012. [XQuery 2.3.1 plus F+O 2.4] If the prerequisites for both errors are satisfied, then either or both may be reported. [XQuery 2.3.1] Re Comment #2: Your concern is perhaps valid, but I think the answer to that is helpful error messages and/or user documentation, not a change to the spec. Conceivably, there could be a special error code for "the static type satisfies the signature appearing in F+O, but not the more precise typing defined by FS 7.2", but I suspect there's a very low chance of that being adopted via an erratum against the published Recommendation. It might have more chance in the context of a future version of the spec. Re Comment #7: I agree that the example wouldn't pass static type analysis: in general, a call to fn:boolean() or fn:data() will not type-check if its argument is declared as item()*. If, as you suggest, STA *didn't* raise a type error, but evaluation raised err:FOTY0012, that would violate this fairly fundamental requirement of XQuery 2.2.3.1: If static type checking raises no errors and assigns a static type T to an expression, then execution of the expression on valid input data is guaranteed either to produce a value of type T or to raise a dynamic error. Or as XQuery 2.2.3.2 puts it: If the Static Typing Feature is in effect, all type errors are detected during static analysis... (Note that err:FOTY0012 is a type error, not a dynamic error.) Therefore, I propose that this issue be closed with no change to the specifications.
The working groups reviewed this issue, and approved the resolution given in Comment #10, namely to close it with no change to the specifications. Consequently, I have marked it INVALID. Please indicate your acceptance of this resolution by marking it CLOSED.
After two years with no response from the original reporter, I am marking this issue CLOSED. Feel free to reopen it if you disagree with this outcome.