This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
At a late stage in the development of XQuery 1.0 (in fact, at the PR stage) a new rule was introduced (see 4.11): It is a static error [err:XQST0093] to import a module M1 if there exists a sequence of modules M1 ... Mi ... M1 such that each module directly depends on the next module in the sequence The definition of "directly depends" means that a dependency only exists if the importing module actually uses a variable or function in the imported module. The published spec also retains the older rule (also in 4.11): A module may import its own target namespace (this is interpreted as importing an implementation-defined set of other modules that share its target namespace.) However, it is a static error [err:XQST0073] if the graph of module imports contains a cycle (that is, if there exists a sequence of modules M1 ... Mn such that each Mi imports Mi+1 and Mn imports M1), unless all the modules in the cycle share a common namespace. The cumulative effect of these rules is that a cycle of imports is permitted in one case only: where two modules share the same namespace but where at least one of the imports is redundant, that is, a module imports another but does not reference anything in the imported module. It seems unnecessarily onerous on implementations, and unhelpful to users, to permit cyclic imports in one situation only, that being a situation where it achieves nothing. I would propose banning all cyclic imports in XQuery 1.0, and removing all restrictions in XQuery 1.1. (In Saxon, incidentally, I currently enforce the restrictions as described in the Rec, but because previous versions of both the product and the spec were more liberal I have a user option to remove all restrictions on cyclic imports and forwards references. There is no conceptual difficulty in doing this; the limitations were introduced at the last minute only because of bugs in the formal semantics.)
I was asked by the WGs (Action A-326-06) to draft a concrete proposal that would ban all cyclical imports. In doing this I wondered how to deal with the sentence "Each module import names a target namespace and imports an implementation-defined set of modules that share this target namespace." The effect of this sentence is that a module can be imported (and can cause cyclicity) without the user actually knowing or intending it. It seems best therefore not to ban cyclical imports, but to ban cyclical dependencies: a dependency is entirely under user control, whereas an import is not. My proposal is therefore as follows: (a) This paragraph is retained unchanged: [Definition: A module M1 directly depends on another module M2 (different from M1) if a variable or function declared in M1 depends on a variable or function declared in M2.] It is a static error [err:XQST0093] to import a module M1 if there exists a sequence of modules M1 ... Mi ... M1 such that each module directly depends on the next module in the sequence (informally, if M1 depends on itself through some chain of module dependencies.) (b) This sentence is deleted, along with error XQST0073: However, it is a static error [err:XQST0073] if the graph of module imports contains a cycle (that is, if there exists a sequence of modules M1 ... Mn such that each Mi imports Mi+1 and Mn imports M1), unless all the modules in the cycle share a common namespace. The effect of this change is that cyclic imports are banned after discounting any pointless imports, a pointless import being one where A imports B but does not reference any variables or functions declared in B. The current spec has the effect that a cycle of imports is permitted only if (a) all the modules share the same namespace, and (b) at least one of the imports is pointless. The revised spec has the effect that a cycle of imports is permitted provided that at least one of the imports is pointless.
I have discussed the feature that modules with a single namespace can be spread over several physical files (which is, I think, the reason for the "Each module import names a target namespace and imports an implementation-defined set of modules that share this target namespace." sentence). I wonder if there is a use case for that. In my personal opinion, this complicates the specification and implementations for no benefit. If it also makes it impossible to properly ban cyclical imports, maybe this feature should be rethought. That somehow collides with the backwards-compatibility thing, though. Maybe I'm missing something, but couldn't all this stuff be a lot simpler? Import a certain module with a certain namespace, make the 'at "..."' location part completely implementation specific, and disallow cyclic imports between modules, where modules are identified (and considered distinct) by their namespaces. Shouldn't that be enough?
Martin, you're not alone in finding the rules for module import unsatisfactory. There's a work item for XQuery 1.1 to make improvements in this area. But we can't do a redesign by means of errata.
Michael, Thank you for this bug report, which was considered by the Query Working Group on April 16, 2007. The working group agreed with your analysis and agreed to make the specification change suggested by your Comment #1. This change will be published in a future erratum. Since you were present for this discussion, I am marking this bug report as Fixed and Closed. Regards, Don Chamberlin (for the Query Working Group)