9600 2010-04-27 18:26:33 +0000 [XQuery 1.1] Importing schema with a simple type conflicting with a function declaration. 2010-06-15 18:38:31 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3.0 Working drafts PC Windows NT RESOLVED FIXED P2 normal --- 1 oliver jonathan.robie jim.melton jmdyck mike public-qt-comments oldest_to_newest 35270 0 oliver 2010-04-27 18:26:33 +0000 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". 35304 1 oliver 2010-04-29 15:21:51 +0000 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?) 35305 2 mike 2010-04-29 15:34:29 +0000 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. 35313 3 jmdyck 2010-04-29 17:31:39 +0000 (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. 35314 4 jmdyck 2010-04-29 17:56:24 +0000 (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." ? 35559 5 jonathan.robie 2010-05-11 16:24:48 +0000 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> 35570 6 oliver 2010-05-11 18:32:43 +0000 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] 35578 7 jonathan.robie 2010-05-11 21:26:09 +0000 (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. 35592 8 mike 2010-05-11 23:06:46 +0000 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. 36187 9 jonathan.robie 2010-06-15 15:00:45 +0000 (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]. 36197 10 jonathan.robie 2010-06-15 18:38:31 +0000 The solution in comment #9 was adopted in today's telcon.