This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(Raised against XPath though the problem really only surfaces in XQuery and XSLT) We use the base URI in the static context for two distinct purposes. It is used to resolve relative URIs in constructs such as "import module", "import schema", "xsl:include", and "xsl:import-schema". Here the usage is at compile time, and the expectation is that the base URI is (by default) the location of the source code in the programmer's development environment. And then it is used in the semantics of expressions such as doc() and resolve-uri(), where the expectation is that it refers to the location from which the stylesheet or query was loaded in the execution environment - what we might call the deployment location. In most real scenarios the development location and deployment location will be different. There are some cases in our specs where it's not obvious which location we really mean. How should relative collation URIs be resolved, for example? Can I use the development location, or should I use the deployment location? I would propose adding a note where we introduce the concept of base URI in the static context that informally points out the existence of these two interpretations and that therefore the "static base URI" used at execution time is not necessarily the same as that used at compile time.
I suggest a non-normative note along these lines: <quote> Note: The Base URI is used for two distinct purposes: 1. Interpreting relative URIs in XDM instances, including XDM instances created by a query. 2. Interpreting relative URIs in a query, including modules, schemas, module URIs, or schema URIs. In many environments, the Base URI used to compile a query may refer to a location known in a development environment, which may be different from the Base URI used to interpret documents at run time. </quote>
In today's meeting, we decided to request a proposal along these lines: 1. There are two different Base URI properties Module Base URI: static context, query-wide, unchanging Document Base URI: dynamic context, query-wide, unchanging 2. They can be declared separately "declare" "module" "base-uri" URILiteral "declare" "document" "base-uri" URILiteral The existing declaration sets both properties: "declare" "base-uri" URILiteral 3. Change "to resolve a relative URI" to take a given base URI as a parameter (see http://www.w3.org/XML/Group/qtspecs/specifications/xquery-30/html/xquery-30.html#dt-resolve-relative-uri) 4. Specific references to resolving a relative URI must each state which base URI is used. I will write a proposal to do this.
Proposal is here: http://lists.w3.org/Archives/Member/w3c-xsl-query/2011Apr/0129.html
>We will also have to sort out which base URI is used for various functions. For instance, I suspect fn:doc should use the Dynamic Base URI rather than the Static Base URI. I propose that we use the principle: if the relative URI can only be written as a literal, then we use the Static Base URI. If the relative URI can be computed at evaluation time then (even if it is written as a literal) we use the Dynamic Base URI. This means for example that collation URIs supplied as arguments to functions are resolved against the dynamic base URI, even if they are supplied as literals, while collation URIs supplied to XQuery "order by" are resolved against the static base URI. (In XSLT, a relative URI supplied to the default-collation attribute is resolved against the static base URI, whereas one supplied to <xsl:sort collation=""/> is resolved against the dynamic base URI, because in this context an AVT is permitted.) I would question whether there is a requirement for a query to discover the static base URI. This would imply that the person executing a query can discover the location where the source query existed at the time it was compiled. I can't see why this is desirable or useful. Unfortunately this leaves us with a function called static-base-uri(), and a requirement to discover the dynamic base URI. To solve this problem, I suggest a change in terminology: from Jonathan's "static base URI" and "dynamic base URI" to "development base URI" and "deployment base URI", with the function static-base-uri() being defined to return the deployment base URI.
The description of fn:static-base-uri() is "Returns the value of the Base URI property from the static context." XQuery currently distinguishes static analysis from dynamic evaluation, and the "static context" is defined as "the information that is available during static analysis of the expression, prior to its evaluation." I agree with you that the static base URI should not be revealed at runtime, so we don't want fn:static-base-uri() to return it. For compatibility reasons, we may want to keep this function, deprecate it, and change its semantics so it returns the dynamic base URI, with a big note warning users that this is what it does. We should then add another method, with a more appropriate name, that does the same thing, and encourage its use. If we add new terminology like "development" and "deployment", we have to be clear about its relationship to static analysis and dynamic evaluation. How is "development" different from "static analysis"? How is the deployment URI different from a dynamic evaluation URI? I worry that having four terms here, rather than two, will confuse rather than clarify. In fact, I might prefer to use terms like "Static Analysis Base URI" and "Dynamic Evaluation Base URI", to be even more clear about the relationship to these phases.
In today's call, we agreed that: 1. XQuery / XPath will the properties Static Base URI / Dynamic Base URI 2. Functions&Operators will still use fn:static-base-uri(), which returns the Dynamic Base URI, and the description will clearly state that.