This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In Section 4.4 p:choose of "XProc: An XML Pipeline Language" has the sentence: "If the selected subpipeline has a primary output port, the port with the same name on the p:choose is also a primary output port." The term "primary output port" is defined (in Section 2.3 Primary Inputs and Outputs) for a step. The specification does not appear to define it for a subpipeline. It goes on to say "The outputs of the p:choose are taken from the outputs of the selected subpipeline. " Since a subpipeline is defined as: subpipeline = p:variable*, (p:for-each|p:viewport|p:choose|p:group|p:try|p:standard-step|pfx:user-pipeline)+ this doesn't appear to include the outputs defined directly within a p:when or p:otherwise wrapper element. Since a p:when is not a step, presumably the result port of <p:identity> is NOT conntected to the declared primary output in the fragment below? <p:choose> <p:when test="true()"> <p:output name="result" primary="true" /> <p:identity /> </p:when> </p:choose> That is, the paragraph from Section 2.3 Primary Inputs and Outputs "Additionally, if a compound step has no declared outputs and the last step in its subpipeline has an unconnected primary output, then an implicit primary output port will be added to the compound step (and consequently the last step's primary output will be connected to it). This implicit output port has no name. It inherits the sequence property of the port connected to it. This rule does not apply to p:declare-step; step declarations must provide explicit names for all of their outputs." does not apply because p:when is not a compound step. I might have suspected that p:choose does not choose between subpipelines, but rather between compound steps, where each p:when or p:otherwise is one such compound step, however the specification makes it clear that p:when and p:otherwise are NOT steps (section 2.1).
Is there likely to be any progress on addressing the bugs reported against XProc? I'd have liked to release an implementation this year, but with the number of unresolved issues in the specification and test suite, we decided to postpone our efforts.
We agree that the spec is a little unclear on this topic; we're exploring alternative ways to describe this in V2. Do the following changes satisfy your concerns? In 4.4, change the first paragraph after the syntax box to read: A p:choose has no inputs. It contains an arbitrary number of alternative branches (identified with p:when and p:otherwise), exactly one of which will be evaluated. And the following change three paragraphs later: After a branch is selected, it is evaluated as if it was a subpipeline and only it had been present. Similar changes are likely to be necessary for p:catch.
Yes. Thanks.