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

[Bug 10978] New: [XQuery10] External variable declaration in main module with same name as another external variable in a library module

From: <bugzilla@jessica.w3.org>
Date: Tue, 05 Oct 2010 15:50:53 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-10978-523@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10978

           Summary: [XQuery10] External variable declaration in main
                    module with same name as another external variable in
                    a library module
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: zongaro@ca.ibm.com
         QAContact: public-qt-comments@w3.org


Consider the following modules.  Will the result of this query always be true?

(: Module A :)
module namespace a = "http://example.org/a";
declare variable $a:ext external;

(: Module B :)
module namespace b= "http://example.org/b";
import module namespace a = "http://example.org/a";
declare variable $b:var := $a:ext;

(: Main module :)
import module namespace b = "http://example.org/b" at "moduleB.xq";
declare namespace a = "http://example.org/a";
declare variable $a:ext external;

declare function local:identical($arg1, $arg2) {
  if (empty($arg1)) then
     empty($arg2)
  else if (empty($arg2)) then
     false()
  else
    ((let $f1 := $arg1[1], $f2 := $arg2[1]
      return
        if ($f1 instance of node()) then
          if ($f2 instance of node()) then
            ($f1 is $f2)
          else
            false()
        else
          ($f1 eq $f2))
     and local:identical($arg1[position() gt 1], $arg2[position() gt 1]))
};

local:identical($a:ext, $b:var)


Notice that the main module declares an external variable, a:ext, with the same
expanded name as a variable in library module A.  My understanding is that this
is not an error.  According to section 4.11 of XQuery 1.0,[1] "It is a static
error if the expanded QName of a variable declared in an imported module is
equal (as defined by the eq operator) to the expanded QName of a variable
declared in the importing module or in another imported module (even if the
declarations are consistent) [err:XQST0049]."  The main module does not import
library module A, so that rule is not contravened.  However, there are two
external variables in the query as a whole whose expanded names are identical.

I can imagine two reasonable implementation strategies for supplying the value
of an external variable:  1) the implementation defines a mechanism for
supplying the value of a variable, identifying it by means of its expanded
name; or 2) the implementation defines a mechanism for supplying the value of a
variable, identifying it by means of its expanded name along with its module
namespace URI, if any.  This by no means exhausts all the possibilities.

Given the first implementation strategy, the result of the query will always be
true.  Right now, both of those implementation strategies seem to be permitted.
 However it seems like an interoperability problem not to improve upon this by
doing one of the following:

1) Make it clear that the two declarations declare the same variable, though
possibly with cumulative type requirements.
2) Make it absolutely clear that they are distinct variables, and that
implementations should enable users to set them independent of one another.
3) Make it an error (or perhaps a violation of a consistency constraint).


Note that external function declarations have the same issue.

[1] http://www.w3.org/TR/xquery/#id-module-import

-- 
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 Tuesday, 5 October 2010 15:50:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:44 UTC