W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2010

[Bug 10863] New: [XQuery11] Contradictory text in rules for importing the same module in multiple places

From: <bugzilla@jessica.w3.org>
Date: Thu, 30 Sep 2010 15:39:53 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-10863-523@http.www.w3.org/Bugs/Public/>

           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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:32 UTC