This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There is currently no deterministic way of getting the base output uri. Typically, this is given as a user option when invoking the stylesheet with the processor, i.e. on the command prompt. The use-case for this is that it allows programmers to have more freedom writing result documents that are relative to the output dir. In addition, many expath-file extensions require a filename argument, allowing the output to be in a certain structure relative to the static output uri can be beneficial. In addition to this it allows for better diagnostics messages during processing, currently the user has no way to say in a diagnostic message which file is being written to. I propose a functon base-output-uri(), analogous to functions like base-uri(). I hope this change is significantly small enough to be allowed during Last Call.
We discussed this in Prague. There was general sentiment that an interrogative for this information would be helpful, and some uncertainty about whether we want to make the change at this stage. It's not disruptive, and it's easy to specify. We concluded that we would like to slip it in.
I thought this would be dead easy until I started thinking about the determinism of the function. We currently allow a stylesheet to be primed once and then evaluated repeatedly. We have written the rules so that base output URI is established when it is primed, rather than when it is evaluated. But that means that by default, each evaluation writes its output to the same place, which doesn't seem very usable. On the other hand, if we allow each evaluation to establish a new base output uri, then the result of the new base-output-uri() function changes on each evaluation, which means (a) it isn't stable, and (b) it's not usable inside a global variable.
We might like to consider the requirement for current-mode() at the same time.
We also say about a primed stylesheet that all global variables, function invocations and stylesheet parameters remain stable. Hence, when you evaluate a primed stylesheet multiple times, you cannot change a stylesheet parameter. I think there is a difference between compiling a stylesheet and priming a stylesheet. When you compile a stylesheet, stylesheet parameters and other environmental information remain volatile, they can change for each invocation of the compiled stylesheet. A primed stylesheet on the other hand, has its global variables and stylesheet parameters fixed. In fact, I don't think there is a problem with (potential) stability of fn:base-output-uri(), not more than there is for fn:system-property() or fn:environment-variable(). The functions are stable after priming, but not after compiling (a phase that is not defined in the spec). Currently there is nothing in the spec that says that the Base Output URI can change on multiple evaluations of a primed stylesheet, but frankly, I think it shouldn't. On a new fn:current-mode(), I concur ;), but other than fn:base-output-uri(), this cannot be a static function.
I think the typical use case for priming a stylesheet once and then invoking it repeatedly is to apply the same processing to a set of input documents, to produce a set of output documents. In thie case the base output URI will be different for each invocation; and the base output URI has no meaning while evaluating global variables. Another approach might be to provide current-output-uri() as the destination of the output currently being written, or null (empty) when in temporary output state (which is always the case when evaluating global variables. This would be an extension to the XSLT part of the dynamic context, so the function would be context-dependent.
Editor has an action to develop the current-output-uri() proposal.
Proposal: add a new XSLT function current-output-uri() -> xs:anyURI? When an instruction is executed in final output state, there is a current output URI. Initially this is the base output URI; executing an xsl:result-document instruction changes the current output URI to the absolute URI established by the href attribute of the xsl:result-document instruction. When the current-output-uri() function is invoked from an instruction executing in final output state, it returns the current output URI as an absolute URI. When the current-output-uri() function is invoked from an instruction executing in temporary output state, it returns the empty sequence. The function is not stable/deterministic. Add a note/example explaining how to capture the base output URI in a tunnel parameter. Add current output URI to the set of XSLT dynamic context components in section 5.4.4. ADDITIONAL CHANGE In section 2.3.2, base output URI is not required when priming a stylesheet, only when invoking a stylesheet component, and it can vary from one invocation to another.
This bug has been looked at and determined that more work needs to be done before moving forward on it. To be considered at the F2F in Hursley.
See also email discussion (member only) at https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Jul/0020.html Proposal: from the current internal draft, change the table entry in 5.4.4, row "current output URI", column "cleared by" to read: Calls to stylesheet functions, dynamic function calls, evaluation of global variables, stylesheet parameters, and patterns In 24.4.1 current-output-uri(), change When the output state is temporary output state, for example while evaluating variables and functions, the current output URI is absent, in which case the function returns the empty sequence. to The current output URI is cleared (set to absent) while evaluating stylesheet functions, dynamic function calls, evaluation of global variables, stylesheet parameters, and patterns. If the function is called when the current output URI is absent, the function returns the empty sequence.
The changes in comment #9 have been applied to the spec.