This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 30413 - [XSLT30TS] current-output-uri-003 etc, relation between output/@file and assert-result-document/@uri not clear
Summary: [XSLT30TS] current-output-uri-003 etc, relation between output/@file and asse...
Status: ASSIGNED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 Test Suite (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Abel Braaksma
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-07 19:11 UTC by Abel Braaksma
Modified: 2019-03-18 12:13 UTC (History)
1 user (show)

See Also:

Attachments

Description Abel Braaksma 2019-03-07 19:11:35 UTC 
It is unclear what the relation is between <output file=.../> and <assert-result-document uri=.../>.

Related historical bug: bug#26755

It is my understanding that output/@file can be used to set the base output URI for the transformation, which itself is relative to the test-set in which it is defined. And that assert-result-document/@uri in turn is relative to this base output URI. 

We are currently not very precise about this:

output/@file documentation:

> Provides a base output URI for the transformation. The processor may 
> (optionally) use this as the location to which serialized output for the 
> principal result tree is written. The location should be given as a relative 
> URI, and should be within a subdirectory of the directory that contains the 
> test set XML file.

assert-result-document/@uri

> The uri corresponds to the URI used in the href attribute of the xsl:result-
> document instruction. It is supplied as a relative URI, interpreted as being 
> relative to the implicit base output URI chosen by the test driver.

I think it is unfortunate we say "relative to the *implicit* base URI, *chosen* by the test driver". Since under the former, we say "provides a base output URI", which suggests that that should be chosen.

--------

I propose to fix this as follows in the documentation:

1) In absence of a specification, base URI and base output URI are the same. (this follows from the base URI being relative to the catalog file (see <source>))
2) output/@file can set the global base output URI, if itself relative, it is relative to the base URI. This has the effect of behaving like it currently does
3) assert-result-document is then relative to (2), in absence thereof, it is relative to (1)

-------

As an example, lets take current-output-uri-003. Prior to rev#1970, this was:

<output file="results/current-output-uri-003.xml"/>
and <assert-result-document uri="results/second/current-output-uri-003.xml">

Following the rules we get (using fn:resolve-uri semantics):

base output URI: tests/fn/current-output-uri/current-output-uri-test-sets.xml
apply @file: tests/fn/current-output-uri/results/current-output-uri-003.xml
apply @uri: tests/fn/current-output-uri/results/results/second/current-output-uri-003.xml

The last @uri would have "results/results" following these rules. 

After rev#1970, this becomes:

<output file="results/current-output-uri-003.xml"/>
and <assert-result-document uri="second/current-output-uri-003.xml">

base output URI: tests/fn/current-output-uri/current-output-uri-test-sets.xml
apply @file: tests/fn/current-output-uri/results/current-output-uri-003.xml
apply @uri: tests/fn/current-output-uri/results/second/current-output-uri-003.xml

------

Note: in *both* cases of resolving the URI, the assertion "ends-with(/out, 'results/second/current-output-uri-003.xml')" will turn up true, but I think the new approach is the way we should resolve such URIs.

I propose to tighten up the documentation to reflect this (and to mark the change in the mentioned test in reference to this bug).
Comment 1 Michael Kay 2019-03-07 23:06:03 UTC 
I think the (new) status quo is that the assert-result-document URI is relative to the implicit or explicit output base URI, so let's stick with that and document it.

If the output base URI isn't explicitly defined in <output file=""> then I think it should be implementation-defined. (NOT the same as the static base URI -- it seems to me a bad idea for a test driver to put output files in a directory that contains input files; too much danger of overwriting by mistake.)

<output file="#absent"/> seems a reasonable suggestion for saying the transformation should run with no base output URI. If the processor doesn't support that, it can always decline to run the test. (I think we can probably find a way for the test driver to invoke Saxon with no base output URI, so long as this is explicitly requested.)
Comment 2 Abel Braaksma 2019-03-08 14:09:21 UTC 
> If the output base URI isn't explicitly defined in <output file=""> then I 
> think it should be implementation-defined.
Yes, that makes sense. I agree that having a default, and that default being the same as the test set location, was a bad idea.

All in all, your and my comments combined, I believe we are in agreement that the status quo is/should be:

* If no base output URI, it is implementation defined

* A base output URI is set by <output file="somebase" />

* That base output URI *must* be a relative URI and is relative to the test-set location (as the documentation currently says)

* Assertions with assert-result-document/@uri will assert the uri-attribute relative to the base output URI, which can be implementation defined.

* <output file="#absent" /> can be used to signify that the initial base output URI is absent. Processors have no requirement to support this.
Comment 3 Abel Braaksma 2019-03-18 12:13:45 UTC 
I've taken the liberty to update the Catalog Schema documentation. Please review whether I caught the results of this discussion properly, so that we can close this bug.