This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
1. I will change this to say "Every valid XQuery 1.0 expression that does not raise an error MUST be valid in XQuery 3.0 and it MUST evaluate to the same result." 2. I will add a statement that says that an XQuery 3.0 processor can return a different result than an XQuery 1.0 processor if the static base URI and dynamic base URI are not the same. Would that fix the problem?
Would that fix the problem?(In reply to comment #0) > "Every valid XQuery 1.0 expression MUST be valid in XQuery > 3.0 and it MUST evaluate to the same result." SNIP > "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). The valid expressions are the ones that do not evaluate to an error. I don't see a need for a change here. > Given the change from using the static base URI to using the dynamic base URI > for resolving many URLs, does this claim hold true? Yes, unless an implementation chooses to use different values for the two. This is a requirements document, I don't think we should say we did not meet the requirement because it's also possible to use settings that give different behavior. Is that a satisfactory answer?
(In reply to comment #1) > 1. I will change this to say "Every valid XQuery 1.0 expression that does not > raise an error MUST be valid in XQuery 3.0 and it MUST evaluate to the same > result." > > 2. I will add a statement that says that an XQuery 3.0 processor can return a > different result than an XQuery 1.0 processor if the static base URI and > dynamic base URI are not the same. > > Would that fix the problem? Ditch this answer. I prefer the answer that I gave in comment #2.
(In reply to comment #3) > Ditch this answer. I prefer the answer that I gave in comment #2. I wasn't really asking for a change to the sentence "Every valid XQuery 1.0 expression MUST be valid in XQuery 3.0 and it MUST evaluate to the same result." as I think it was obvious what the intent was. That said, if I were being pedantic, the only references to what a 'valid' XQuery expression might be in XQ30 refers to syntactic validity. However validity could mean: 1. syntactically valid with respect to the EBNF 2. valid with respect to static analysis (e.g. type checking) 3. valid with respect to dynamic execution (not raising errors) fn:error() is syntactically valid, valid with respect to static analysis, but does raise an error. Regarding "Yes, unless an implementation chooses to use different values for the two. This is a requirements document, I don't think we should say we did not meet the requirement because it's also possible to use settings that give different behavior." It is not always possible to use settings to give the same answer. I'll try to put a set of examples together to demonstrate this.
>It is not always possible to use settings to give the same answer. I'll try to put a set of examples together to demonstrate this. I think this is the crux of the matter. You've raised a number of test bugs, Tim, that seem to have this belief at their heart. I'm looking forward to seeing your examples. From my perspective (and it was I who introduced the split between development-time base URI and deployment-time base URI, since renamed), it is always possible to have the two base URIs the same, if only by compiling source code in the location where the object code is deployed.
<?xml version="1.0" ?> <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <foo xml:base="http://www.exmaple.org/foo"> <xsl:value-of select="static-base-uri()" /> </foo> <bar xml:base="http://www.exmaple.org/bar"> <xsl:value-of select="static-base-uri()" /> </bar> </xsl:template> </xsl:stylesheet> An XSLT 2.0 processor will produce <foo xml:base="http://www.exmaple.org/foo"> http://www.exmaple.org/foo </foo> <bar xml:base="http://www.exmaple.org/bar"> http://www.exmaple.org/bar </bar> When using F&O 3.0, this will surely be something like <foo xml:base="http://www.exmaple.org/foo"> http://value/of/the/dynamic/base/URI </foo> <bar xml:base="http://www.exmaple.org/bar"> http://value/of/the/dynamic/base/URI </bar>
*** This bug has been marked as a duplicate of bug 17595 ***
The remaining portion is now a duplicate of 17595, which is now resolved.