W3C home > Mailing lists > Public > xproc-dev@w3.org > September 2011

document base uri

From: Romain Deltour <rdeltour@gmail.com>
Date: Thu, 22 Sep 2011 00:51:48 +0200
Message-Id: <51128456-EB0A-42CA-9E19-4AE39D70BF52@gmail.com>
To: XProc Comments <public-xml-processing-model-comments@w3.org>
Cc: XProc Dev <xproc-dev@w3.org>

It seems the general approach for XProc steps is that if an attribute  
named "xml:base" is added (or changed), the base URI of the underlying  
element MUST be updated [1].

However, there seems to be no simple way [*] to change the base URI of  
a *document* flowing through a pipeline. This makes the no-arg p:base- 
uri() function (returning the context document base URI) very brittle  
whenever @xml:base is manipulated.

I think it would be better to say: if an attribute named "xml:base" is  
added (or changed), the base URI of the underlying element MUST be  
updated ; if the underlying element is the root element, the base URI  
of the document MUST be updated.

Note that the introduction of section 7 [2] is confusing for the same  
	"When a step in this library produces an output document, the base  
URI of the output is the base URI of the step's primary input document  
unless the step's process explicitly sets an xml:base attribute (...)"

Comments welcome!

[1] http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2009Jan/0040.html
[2] http://www.w3.org/TR/xproc/#std-components
[*] I tried several solutions:

    a) adding an @xml:base (e.g. with p:add-attribute) affects an  
element, not the document node.

    b) using a p:xslt with @output-base-uri and an identity XSLT seems  
to work with XSLT 1.0-enabled processors (e.g. Calumet), not with XSLT  
2.0-enabled ones (e.g. Calabash).
I suppose it's because Calumet uses XSLT 1.0 ("An XSLT 1.0 step should  
use the value of the output-base-uri as the base URI of its output")  
and Calabash XSLT 2.0 (which doesn't specifies, as far as I  
understood, that the base output URI sets the base URI of an  
implicitly constructed final result tree).

    c) I could get something working by using an XSLT 2.0 identity  
that writes on an explicit xsl:result-document, then discarding the  
main result port, wrapping/unwrapping the secondary sequence port to  
get the single result document.

I attached some XProc documents showing the approaches described above.

Romain Deltour, Software Developer
The DAISY Consortium

Received on Wednesday, 21 September 2011 22:52:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:08 UTC