This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I think there is a couple of areas concerning external functions that are left unspecified, that it is not instructed or specified to be implementation defined/dependent how certain aspects of external functions are handled. I think it is clear that how the calling conventions to an external function is carried out is implementation defined. However, some aspects concerning the actual external declaration is vague. Examples: How should an implementation treat the following query? declare namespace e = "example.org/An ns which is not supported"; declare function e:notSupported() external; 1 eq 1 If an implementation may do anything, I think a sentence should say "It is implementation defined how an external function declaration is handled", or similar. Wouldn't it be sensible to require an implementation to raise an error if an external declaration is encountered that specifies a function it does not support? That is, that the above query always fails to compile. XPST0017 refers to invalid function calls; perhaps the scope of that error code could be widened, or that a new error code is added. Also, I think the following query encounters similar problems: declare function fn:deep-equal(arg as item()*, arg2 as item()*) as xs:boolean external; 1 eq 1 I don't see it specified how an implementation are supposed to handle it. I don't see the advantages of not having a strict approach; that the above query should result in an error. That is, that the 'reserved namespaces' clause should not only apply to user defined functions, but also external function declarations. This was first brought to discussion on public-qt-comments mailinglist, subject "Intent of 'declare function ... external'". Frans
Frans, On 14 March 2006, the Query Working Group discussed your suggestion. The working group believes that errors in external functions should be raised when the function is called rather than when it is declared. The working group decided to make the following changes to the XQuery specification: (1) Add a consistency constraint to Section 2.2.5 (following the constraint on external variables: "For each function declared as external: the [function implementation] must either return a value that matches the declared result type, using the matching rules in [2.5.4 SequenceType Matching], or raise an implementation-defined error." (2) In Section 3.1.5 (Function Calls), Rule 4, change "If the function is a user-declared function" to "If the function is a user-declared function that has a body". (3) In Section 3.1.5 (Function Calls), add a new Rule 5: "If the function is a user-declared external function, its [function implementation] is invoked with the converted argument values. The result is either a value of the declared type or an [implementation-defined] error (see [2.2.5 Consistency Constraints]). (d) In Appendix E (Implementation-Defined Items), add a new entry: The result of an unsuccessful call to an external function (for example, if the function implementation cannot be found or does not return a value of the declared type). Since we believe that these changes address your concerns, I have marked this Bugzilla entry as "Fixed". If you are satisfied with this resolution, please change the status of the Bugzilla entry to "Closed". If you take no action, the working group will close this entry at the end of March. Regards, Don Chamberlin (for the Query Working Group)
I think what addressed my concerns was not the specification changes, but comment #1, which said: "The working group believes that errors in external functions should be raised when the function is called rather than when it is declared". I'm trying to understand that; why is it so? What is the purpose of letting the following query compile? declare namespace e = "example.org/An ns which is not supported"; declare function e:notSupported() external; 1 eq 1 I like the idea in principle, because it disallows weird code. However, I have understanding for if this area is considered too much of a corner case in order to justify changing the spec. I'm primarily trying to understand the philosophy behind "errors should be raised when the function is called rather than when it is declared". I would find it interesting to see an example of where an implementation see a purpose in silently accepting an function declaration specifying an unsupported external function. Note, I'm only looking for clarification, so a personal response is fine. I'll express my consent on resolution later on. Regards, Frans
If you are in a world where you are doing separate compilation, or if those external functions are _really_ external (like, say, bound to web services), detecting this statically may be difficult, impossible, or just plain wrong (your network connection goes down half-way through execution). Implementations that could detect this statically are always free to issue the error at that time. //Mary (Personal response)
Thanks Mary for the clarification, the current design makes now more sense to me. I'm satisfied with the solution and therefore change the status to CLOSED. Frans