This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A number of functions, such as local-name(), name(), base-uri() etc default the first argument to the context item. It might be thought that name() and name(.) are precisely equivalent; indeed, it might be thought that the function call name() could be statically rewritten to name(.). However, the behaviour of the two function calls is different in error cases. If the context item is not a node, name(.) throws XPTY0004 while name() throws FOTY0011. If the context item is undefined, name(.) throws XPDY0002 while name() throws FONC0001. It's inconvenient for the implementation to have to generate different executable code for these two constructs just so that different error codes can be generated at run-time. The distinction doesn't seem particularly helpful to the user. I propose that the behaviour of name() and similar functions should be the same as name(.) even in error cases. Michael Kay
Here is a full list of the affected functions. In each case the proposal is that the call on the left should be equivalent to the call on the right even in error cases (it is already equivalent in success cases). base-uri() => base-uri(.) id(x) => id(x, .) idref(x) => idref(x, .) lang(x) => lang(x, .) local-name() => local-name(.) name() => name(.) number() => number(.) namesapce-uri() => namesapce-uri(.) root() => root(.) string() => string(.) The following cases are "almost equivalent" (but not quite - string-length(3) is a type error, but string-length(.) where . is 3 is allowed). In these cases I propose that we also use the same error code for the error cases, for consistency with the list of functions above: string-length() => string-length(string(.)) normalize-space() => normalize-space(string(.)) Example of changes in detail: base-uri: delete "If $arg is not specified, returns the value of the base-uri property of the context item (.) with the above semantics. If the context item is not a node, an error is raised: [err:FOTY0011]. If the context item is undefined, an error is raised: [err:FONC0001].". Instead say "If $arg is not specified, the effect is the same as calling fn:base-uri(.), including possible error cases when the context item is undefined or is not a node.". Other functions: similarly, say at the start that the semantics when the argument is omitted are the same as when "." is provided as the argument, and thereafter avoid discussing this case further. string-length() and normalize-space() need a little more care because this equivalence doesn't hold: instead, it's probably best to simply change the error codes for "context item not defined" to XPDY0002. These changes remove all uses of FOTY0011, but FODC0001 remains in use for position() and last().
I agree that we should make it clear that for these functions fn() has the same semantics as fn(.) but I am uncomfortable leaving the error conditions out of the description. Thus, I would recommend that we change the descriptions of the functions as per the example below. base-uri: delete "If $arg is not specified, returns the value of the base-uri property of the context item (.) with the above semantics. If the context item is not a node, an error is raised: [err:FOTY0011]. If the context item is undefined, an error is raised: [err:FONC0001].". Instead say "If $arg is not specified, the effect is the same as calling fn:base-uri(.) with the following error conditions: if the context item is not a node, an error is raised: [err:FOTY0011]. If the context item is undefined, an error is raised: [err:FONC0001].".
On the February 14 telcon the joint WGs agreed to make the changes are suggested by Michael Kay and amended by Ashok Malhotra.
Ashok, could you check this one more time? As I see it, Michael's key points are that: * "These changes remove all uses of FOTY0011" * And to use XPDY0002 more; "it's probably best to simply change the error codes for "context item not defined" to XPDY0002." * That instead of FOTY0011 is XPTY0004 raised when the context item should evaluate to a node but doesn't. However, I think the proposed wording in comment #2 is not consistent with that: "If $arg is not specified, the effect is the same as calling fn:base-uri(.) with the following error conditions: if the context item is not a node, an error is raised: [err:FOTY0011]. If the context item is undefined, an error is raised: [err:FONC0001]." To me, it also looks like it is identical to what error codes that currently are invoked. (Btw, I think that when Michael at the very end wrote "but FODC0001 remains in use for position() and last()," that FONC0001 was intended.) Frans
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.