This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Test xqhof16 makes use of fn:static-base-uri. declare base-uri "main"; import module namespace lib = "lib"; lib:getfun()(), fn:static-base-uri#0(), fn:static-base-uri() There are several problems with this test. As it currently stands, in XQ30 fn:static-base-uri doesn't return the static base uri. Therefore the base-uri declaration has no bearing on the result. Even if it did, "main" is a relative URI, and thus fn:static-base-uri still might (would?) not return "main". With the current definition of fn:static-base-uri, this will return the same result regardless of the module in which it appears. There are similar problems in xqhof18.
Would it help if we stated a constraint on the test environment that the dynamic base URI of every module is the same as its static base URI? I would expect that to be easily achieved for most implementations, simply by executing the query in the same location as where the source code is located.
(In reply to comment #1) > Would it help if we stated a constraint on the test environment that the > dynamic base URI of every module is the same as its static base URI? I would > expect that to be easily achieved for most implementations, simply by executing > the query in the same location as where the source code is located. It might lead to some implementation bugs being more difficult to tease out. Note that this test uses a module. There's a call to fn:static-base-uri from lib which the test author believed would return lib, when in fact it should be (in XQ30) the dynamic base URI. I really do not like having fn:static-base-uri returning something which isn't the static base URI. It just leads to confusion.
>I really do not like having fn:static-base-uri returning something which isn't the static base URI. It just leads to confusion. I agree wholeheartedly. That's why I resisted this choice of terminology. I would much prefer to call the two concepts "source location" and "deployment location" and have static-base-uri return the "deployment location". That far better reflects the original intent of the split.
As we're stuck with fn:static-base-uri() for compatibility with F&O 1.0, I'd suggest fn:current-uri() for the dynamic base URI/deployment location, because so many of the dynamic context accessors start with "current".
The problem is that in practice, the static-base-uri() function is used to locate resources such as lookup documents (configuration files etc) which exist in the dynamic environment where the query is deployed; it is not used to find out where the source code was when it was compiled. For compatibility, static-base-uri() needs to continue to return the deployment location. We don't need a function to tell you where the source code was when it was compiled: there is no reason we should want to make this information available.
(In reply to comment #5) > The problem is that in practice, the static-base-uri() function is used to > locate resources such as lookup documents (configuration files etc) which exist > in the dynamic environment where the query is deployed; it is not used to find > out where the source code was when it was compiled. > > For compatibility, static-base-uri() needs to continue to return the deployment > location. We don't need a function to tell you where the source code was when > it was compiled: there is no reason we should want to make this information > available. I'm afraid I don't agree with this. An XQuery base-uri declaration can set the base URI to any value it likes. It need have no relation to either where the source code resided or to the URI at query is deployed.
>An XQuery base-uri declaration can set the base URI to any value it likes. Not sure I understand what you're saying here. We seem to have decided that the base-uri declaration affects only the "static base URI", which means it's only used (directly) for resolving compile-time things like import module and import schema. I would expect most implementations to make the static base URI and dynamic base URI the same by default, in which case I guess it will determine the dynamic base URI as well, but I don't quite see the relevance of this to your remark.
(In reply to comment #7) > >An XQuery base-uri declaration can set the base URI to any value it likes. > > Not sure I understand what you're saying here. We seem to have decided that the > base-uri declaration affects only the "static base URI", which means it's only > used (directly) for resolving compile-time things like import module and import > schema. I would expect most implementations to make the static base URI and > dynamic base URI the same by default, in which case I guess it will determine > the dynamic base URI as well, but I don't quite see the relevance of this to > your remark. As you've pointed out, in XQuery 1.0 there was no distinction between the static base URI and the dynamic base URI. Providing both are the same, existing XQuery 1.0 queries will continue to be unaffected when run under a 3.0 processor. However, one cannot always guarantee that the staitc base URI and dynamic base URI will be the same. This has the potential to break existing queries. Examples of this include use of a function which relies on the static base URI from a library module whose static base URI is different from the static base URI of the importing module. Or something like: <?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> Or am I missing something?
Following from spec changes I think this one can be closed now.
I disagree. I would expect fn:static-base-uri() to be returning absolute URIs. The expected results are not absolute URIs.
(In reply to comment #10) Yes I agree. I have changed the expected results of the test-cases so that we use the fn:ends-with() function.
"The assert element contains an XPath expression whose effective boolean value must be true; usually the expression will use the variable $result which references the result of the expression. " The assertion <assert>fn:ends-with($result[1], "lib"), fn:ends-with($result[2], "main"), fn:ends-with($result[3], "main")</assert>" does not have an EBV. I suspect you meant <all-of> <assert>fn:ends-with($result[1], "lib")</assert> <assert>fn:ends-with($result[2], "main")</assert> <assert>fn:ends-with($result[3], "main")</assert> </all-of> It might be better to omit the "fn" prefix, as this isn't a predefined namespace for XPath.
Yes you are right. I have made the fix to the expected results of both test cases.