Bug 17281 - [QT3TS] xqhof16, xqhof18
[QT3TS] xqhof16, xqhof18
Status: CLOSED FIXED
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite
Working drafts
PC Windows NT
: P2 normal
: ---
Assigned To: O'Neil Delpratt
Mailing list for public feedback on specs from XSL and XML Query WGs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-01 10:14 UTC by Tim Mills
Modified: 2012-10-05 15:58 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Mills 2012-06-01 10:14:12 UTC
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.
Comment 1 Michael Kay 2012-06-01 10:32:27 UTC
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.
Comment 2 Tim Mills 2012-06-01 10:37:44 UTC
(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.
Comment 3 Michael Kay 2012-06-01 11:03:55 UTC
>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.
Comment 4 Tim Mills 2012-06-01 11:24:19 UTC
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".
Comment 5 Michael Kay 2012-06-01 11:36:56 UTC
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.
Comment 6 Tim Mills 2012-06-01 12:15:03 UTC
(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.
Comment 7 Michael Kay 2012-06-01 13:06:08 UTC
>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.
Comment 8 Tim Mills 2012-06-01 13:30:29 UTC
(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?
Comment 9 O'Neil Delpratt 2012-09-25 14:19:05 UTC
Following from spec changes I think this one can be closed now.
Comment 10 Tim Mills 2012-09-25 15:13:58 UTC
I disagree.

I would expect fn:static-base-uri() to be returning absolute URIs.

The expected results are not absolute URIs.
Comment 11 O'Neil Delpratt 2012-10-01 15:49:12 UTC
(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.
Comment 12 Tim Mills 2012-10-02 12:54:57 UTC
"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.
Comment 13 O'Neil Delpratt 2012-10-02 13:56:37 UTC
Yes you are right. I have made the fix to the expected results of both test cases.