- From: Romain Deltour <rdeltour@gmail.com>
- Date: Thu, 22 Sep 2011 17:16:01 +0200
- To: Geert Josten <geert.josten@daidalos.nl>
- Cc: XProc Dev <xproc-dev@w3.org>
The XProc model is based on the XML Information Set [1], which does allow a base URI on both document and element items. As Norm correctly pointed out on the XProc Comment list [2], the problem is with XML processing instructions which can have a base URI too. Adding an xml:base attribute to the root element shouldn't change the base URI of sibling PIs... so my proposal wouldn't work. It seems we all agree that a 'p:base-uri' step changing the base URI of the document would be a nice addition. Romain. [1] http://www.w3.org/TR/xproc/#infoset-conformance [2] http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2011Sep/0003.html Le 22 sept. 11 à 12:59, Geert Josten a écrit : > Hi Romain, > > Interesting! I had similar problems when I tried to rely on base-uri > to keep track from which file certain (processed) trees came from. I > was forced to use base-uri(/*) to work around this problem. I am not > sure though that setting a xml:base attribute on the root element to > change the base-uri of the document node is the best solution. > > First of all, I am curious what the XML Base spec would say about > the difference between the two (base-uri of document node versus > xml:base on root element), does it distinguish between the two? > > Secondly, I would make more sense to me to have a p:change-base-uri > step that *would* allow changing the base-uri property of the > document node. > > WDYT? > > Kind regards, > Geert > > -----Oorspronkelijk bericht----- > Van: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] > Namens Romain Deltour > Verzonden: donderdag 22 september 2011 0:52 > Aan: XProc Comments > CC: XProc Dev > Onderwerp: document base uri > > Hi, > > 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 > reason: > "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! > Romain. > > > [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 > http://www.daisy.org
Received on Thursday, 22 September 2011 15:16:34 UTC