This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider a schema in namespace "http://www.example.org/" that defines a type example:foo. Consider the following module, also in namespace "http://www.example.org/". declare module namespace example="http://www.example.org/"; declare function example:foo($x as item()) { $x } This function declaration is valid, as the schema has not been imported and there is no conflict with any in scope function. Now consider a query which imports both this module, and the schema: import module namespace example="http://www.example.org/"; import schema namespace example="http://www.example.org/"; example:foo(1) Clearly we have a problem here; does the example:foo function call refer to the constructor or the user defined function. Surely there should have been an error raised when importing the module/schema. The spec makes it quite clear (in section 4.17) that an XQST0034 error should be raised if the function was declared when the schema was in scope, although this is not the case here (as the schema was not imported in the module) The equivalent rules for this error when importing a module (section 4.12) state: It is a static error if the expanded QName and arity of a function declared in an imported module are respectively equal to the expanded QName and arity of a function declared in the importing module or in another imported module (even if the declarations are consistent) [err:XQST0034] Since the schema constructor is not "a function declared in the importing module or in another imported module" this does not hold either. I suggest that the above text should be modified to include also the case where "an imported function has arity 1 and has an expanded QName which is equal to the expanded QName of an atomic type defined in a schema imported by the importing module".
There is a similar problem when importing a schema (in the fn namespace) with an atomic type that conflicts with the name of one of the built in functions. Since these functions are never declared the error condition does not apply. (On a side note is it intentional that a module can be written in the fn namespace, but the module cannot contain any functions?)
Arguably we should rely more on declarative statements of constraints, like this one in 2.1.1: "Each function is uniquely identified [within the static context] by its expanded QName and its arity (number of parameters).", and worry less about enumerating all the situations that can cause the constraint to be violated. Though it makes a useful test case for implementations.
(In reply to comment #0) > > I suggest that the above text should be modified to include also the case where > "an imported function has arity 1 and has an expanded QName which is equal to > the expanded QName of an atomic type defined in a schema imported by the > importing module". Rather than going to that level of detail, we could use the concept of 'constructor functions', e.g., add a clause about functions "implicitly defined by a schema import in the importing module". Another approach would be to avoid listing the various places where a function could come from, and just refer to the 'function signatures' component of the static context.
(In reply to comment #2) > Arguably we should rely more on declarative statements of constraints, like > this one in 2.1.1: "Each function is uniquely identified [within the static > context] by its expanded QName and its arity (number of parameters).", and > worry less about enumerating all the situations that can cause the constraint > to be violated. So then we'd just say something like "It is a static error [err:XQST0034] if any situation causes that constraint to be violated." ?
I propose we add an error to the section on constructors: 3.14.5 Constructor Functions For every atomic type in the in-scope schema types (except xs:NOTATION and xs:anyAtomicType, which are not instantiable), a constructor function is implicitly defined. <add> If a constructor function has the same name and arity as an existing function in the function signatures, a static error [err:####] is raised. </add>
Does this entirely cover us? If we import the schema before the module first then do the function signatures yet include the ones from the module? It might be worth also changing (XQ 4.12) It is a static error if the expanded QName and arity of a function declared in an imported module are respectively equal to the expanded QName and arity of a function declared in the importing module or in another imported module (even if the declarations are consistent) [err:XQST0034] to: It is a static error if the expanded QName and arity of a function declared in an imported module are respectively equal to the expanded QName and arity of an existing function in the function signatures (even if the declarations are consistent) [err:XQST0034]
(In reply to comment #6) > It might be worth also changing (XQ 4.12) > > It is a static error if the expanded QName and arity of a function declared in > an imported module are respectively equal to the expanded QName and arity of a > function declared in the importing module or in another imported module (even > if the declarations are consistent) [err:XQST0034] > > to: > > It is a static error if the expanded QName and arity of a function declared in > an imported module are respectively equal to the expanded QName and arity of an > existing function in the function signatures (even if the declarations are > consistent) [err:XQST0034] I agree. I suspect these two changes should be sufficient.
The word "existing" seems to imply a particular order of processing. It's surely possible to express the error as a constraint that doesn't depend on order of processing.
(In reply to comment #8) > The word "existing" seems to imply a particular order of processing. It's > surely possible to express the error as a constraint that doesn't depend on > order of processing. I think the existing text for module import does this nicely. I think we should simply echo this in the text for schema import, using the same language and the same error code to emphasize the parallelism between the two: 4.12 Module Import (current) It is a static error if the expanded QName and arity of a function declared in an imported module are respectively equal to the expanded QName and arity of a function declared in the importing module or in another imported module (even if the declarations are consistent) [err:XQST0034]. 4.11 Schema Import (proposed) It is a static error if the expanded QName and arity of a <diff>constructor function</diff> are respectively equal to the expanded QName and arity of a function declared in the importing module or in another imported module (even if the declarations are consistent) [err:XQST0034].
The solution in comment #9 was adopted in today's telcon.