- From: Paul Tyson <phtyson@sbcglobal.net>
- Date: Tue, 29 Jul 2014 19:58:27 -0500
- To: xproc-dev@w3.org
A couple of related questions regarding the uri of documents produced on the "result" and "secondary" output ports of the p:xslt step. First, it was unclear from the specs how an xproc implementation would distinguish the "primary" result document from all the others. A little experimentation in calabash (1.0.18-95) seemed to prove that the "primary" document was the one that was *not* produced from an <xsl:result-document> instruction. If there is no such document, the "result" output port sees an empty sequence (which was the first mystery I had to solve). Question #1: Is this the expected behavior per spec, or implementation-specific? In either case, it would be good if the spec either clarified the expectation or stated that this was an implementation choice. Looking back with what I know now, it seems calabash is doing the sensible thing, but I still can't piece together the right paragraphs in the xproc and xslt2 specifications to justify this. Having settled that issue, I then tried to set the uri of the default, or primary, result document. With <xsl:result-document>, you just set the href attribute. In my case it worked to use a relative uri in the stylesheet, and set the output-base-uri on the p:xslt step. Then subsequent steps could use the document-uri() associated with each result document. But due to the apparent asymmetry in setting document uris on the "primary" and "secondary" output of xslt, I need some other way to conditionally process the primary results from p:xslt. I could find no way to add the document uri during or after the xslt step. As far as I can tell it comes out with an empty document-uri, which seems to be as specified by xslt2 for the default result document. I tried setting xml:base on various elements, but nothing worked. Question #2: Is there a way to set document-uri on an intermediate document in an xproc pipeline? I could work around this by putting all xslt output documents on the secondary output port (by wrapping the default in <xsl:result-document>). Then I need do do a little extra work to find the "primary" document for any special processing it alone requires. And I need to "sink" the "result" port output, since it is the primary xslt output port and will be empty. Thanks for any thoughts and suggestions. Regards, --Paul
Received on Wednesday, 30 July 2014 00:59:49 UTC