- From: <bugzilla@jessica.w3.org>
- Date: Thu, 30 Sep 2010 15:39:53 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10863 Summary: [XQuery11] Contradictory text in rules for importing the same module in multiple places Product: XPath / XQuery / XSLT Version: Member-only Editors Drafts Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: XQuery 1.1 AssignedTo: jonathan.robie@redhat.com ReportedBy: oliver@cbcl.co.uk QAContact: public-qt-comments@w3.org Group: XSLXQuery_WG Section 4.12.2 defines the rules for importing the same module in multiple places. It contains the following sentence: In an environment where a group of modules can be compiled as a unit, an implementation may consider a module used in the compiled unit distinct from another instance of the same module imported from elsewhere in the query. It took me about 10 minutes staring at this sentence until I could fathom what it possibly meant! I assume it covers the following case: You compile a module M1 that imports a module P1 with URI P. You compile a module M2 that also imports P2 with URI P. You then wish to compile a query that imports M1 and M2. It is alright if M1 and M2 use different instances of module P. (i.e. if P1 and P2 have conflicting functions they don't have to be reported, and that if P1 is the same module as P2 then global variables are seperate instances, and may even have different values. Essentially this allows static linking in compilation. However this directly contradicts the preceding paragraphs! If this is not the intended meaning of this sentence then it could be made a lot clearer. One way to fix this is to drop this sentence I see no inherent reason for this limitation: An implementation can ensure that there is only one compiled version of each library module. These modules can quite happily have their functions and variables bound to each other. When the query is compiled all that needs to be checked is the constraint that no function names conflict. I suspect the rule must have been added because of feedback from an implementor, so I assume this is not a viable option. The other solution is to make the preceding text more lax: Essentially this section lays out a series of rules and then says (vaguely) you can ignore these rules in an environment where modules are compiled. The contradiction could be eliminated by changing all of the occurences of the word "must" in this section to "should", and change the last sentence to a note explaining that one case in which you would choose not to do this is in an environment where modules are compiled statically. An example explaining why (like the example above) would not be amiss either! -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Thursday, 30 September 2010 15:39:55 UTC