W3C home > Mailing lists > Public > public-qt-comments@w3.org > March 2012

[Bug 16583] New: [XQ30] Compatibility Claims

From: <bugzilla@jessica.w3.org>
Date: Fri, 30 Mar 2012 16:06:23 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-16583-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16583

           Summary: [XQ30] Compatibility Claims
           Product: XPath / XQuery / XSLT
           Version: Member-only Editors Drafts
          Platform: PC
               URL: http://www.w3.org/TR/xquery-30-requirements/#backward-
                    compatibility
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 3.0
        AssignedTo: jonathan.robie@gmail.com
        ReportedBy: tim@cbcl.co.uk
         QAContact: public-qt-comments@w3.org


In XQuery 3.0 Requirements section 2.2.1 (Backward compatibility)

http://www.w3.org/TR/xquery-30-requirements/#backward-compatibility

it is stated that "Every valid XQuery 1.0 expression MUST be valid in XQuery
3.0 and it MUST evaluate to the same result."  It is also claimed that this
requirement has been met.  In XQuery 3.0 appendix J1 (incompatibilities) it is
stated that "No change in this specification introduces an incompatibility with
XQuery 1.0."  I take this to mean any expression which does not evaluate to an
error, since that would prohibit relaxing of some restrictions of XQeery 1.0
(e.g. casting to xs:QName).

Given the change from using the static base URI to using the dynamic base URI
for resolving many URLs, does this claim hold true?

An obvious difference is that the expression

(fn:static-base-uri(), fn:base-uri(<a />))

can give completely different results when executed with an XQuery 1.0
processor and an XQuery 3.0 processor..

Taking F&O out of the equation, I would still claim that

<a />

gives different results, since in XQuery 1.0 the base-uri property of the
element will be that of the static base URI, while in XQuery 3.0 its base-uri
property will be that of the dynamic base URI.

XQuery 1.0 did not separate the concepts of static base URI and dynamic base
URI: in effect they were always the same. In an XQuery 3.0 environment, if the
static base URI and dynamic base URI are the same, then the query will deliver
the same results as XQuery 1.0. So if you run the same query in the same
context, it produces the same result. 

However, while that holds within a single module, if a query uses two modules
with different static base URIs S1 and S2 (S1 not equal to S2) then surely it
cannot be arranged for the dynamic base URI to be equal to both S1 and S2.  The
location of execution of a query doesn't change across module boundaries, as
evidenced by

https://www.w3.org/XML/Group/qtspecs/specifications/xquery-30/html/xquery-30.html#eval_context

[Definition: Dynamic Base URI. This is an absolute URI, used to resolve
relative URIs during dynamic evaluation.] The URI value is whitespace
normalized according to the rules for the xs:anyURI type in [XML Schema 1.0] or
[XML Schema 1.1]. The Dynamic Base URI corresponds to the location in which the
query is executed; it is set by the implementation. 

(Unfortunately the XQuery 3.0 specifications no longer lists a "scope" column
in appendix C.2 Dynamic Context Components.  Had it, I would have expected the
dynamic base URI to be listed as having "global" scope as opposed to "module"
scope for the static base URI).

In XQuery 3.0 fn:static-base-uti() will always return the same result in all
modules of a query (because it actually returns the dynamic base URI), which
was not the case in XQuery 1.0. 

If my argument is correct, then possible solutions are:

A. Admit the incompatibility.

B. Reduce the level of incompatibility by:

1) reverting fn:static-base-uri() to return the property from the static 
context

2) provide fn:dynamic-base-uri() to return the property from the dynamic
context

3) reverting the behaviour of string functions taking a collation argument to
resolve against the static base URI (since available collations are part of the
static context)

4) admit the remaining incompatibility in cross-module use of functions such as
resolve-uri and doc which previously resolved relative URI arguments against
the static base URI but now resolve against the dynamic base URI.

5) admit the reamining incompatibility resulting from the change in base URI of
constructed nodes from static base URI to dynamic base URI.

-- 
Configure bugmail: https://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 Friday, 30 March 2012 16:06:29 UTC

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