Bugzilla – Bug 21006
Errors in Section 4.4 p:choose
Last modified: 2014-02-19 14:42:29 UTC
In Section 4.4 p:choose of "XProc: An XML Pipeline Language" has the
"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
Since a subpipeline is defined as:
subpipeline = p:variable*,
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:output name="result" primary="true" />
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.