W3C home > Mailing lists > Public > xproc-dev@w3.org > July 2014

Re: setting uri on primary output of xslt

From: Romain Deltour <rdeltour@gmail.com>
Date: Wed, 30 Jul 2014 08:51:02 +0200
Message-Id: <5137B59D-3C87-46E1-A411-B2A75BBC56C3@gmail.com>
To: xproc Dev <xproc-dev@w3.org>, Paul Tyson <phtyson@sbcglobal.net>

On 30 juil. 2014, at 02:58, Paul Tyson <phtyson@sbcglobal.net> wrote:

> 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.

Yes, I’m pretty sure it’s the intended behavior defined by the *spec* (not implementation-specific). The relevant lines in the XProc spec are:

  "The primary result document of the transformation appears on the result port. All other result documents appear on the secondary port.”

But I agree that this can be confusing since the XSLT spec doesn’t define the term “primary result document” of a transformation. XSLT instead uses the term “final result tree”, and doesn’t explicitly name the primary result document other than with something like “final result tree implicitly created by the initial template”.

By the way, I would believe that if the XSLT initial template doesn’t implicitly create a final result tree *but* there is an <xsl:result-document> instruction with an empty href, then that would be passed to the primary result port in XProc ?

I definitely agree the XProc spec would need clarification here.

> 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.

About that issue, see that other thread:

And related bugs:

About the "apparent asymmetry” thing, have you tried using an <xsl:result-document> with empty href instead of an implicitly created final result tree ?

> Question #2: Is there a way to set document-uri on an intermediate
> document in an xproc pipeline?

Calabash provides a <pxp:set-base-uri> step since 1.0.17, and this will hopefully be standardized in XProc 2.0 (or wherever the VNext standard step library will be specified).

Hope this helps!

> 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 06:51:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:17:20 UTC