Bug 21006 - Errors in Section 4.4 p:choose
Summary: Errors in Section 4.4 p:choose
Alias: None
Product: XML Processing Model
Classification: Unclassified
Component: Pipeline language (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Norman Walsh
QA Contact:
Depends on:
Reported: 2013-02-15 08:43 UTC by Tim Mills
Modified: 2014-02-19 14:42 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Tim Mills 2013-02-15 08:43:44 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 
subpipeline. "

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:when test="true()">
     <p:output name="result" primary="true" />
     <p:identity />

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).
Comment 1 Tim Mills 2013-12-17 10:29:13 UTC
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.
Comment 2 Norman Walsh 2014-02-19 12:16:46 UTC
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.
Comment 3 Tim Mills 2014-02-19 14:42:29 UTC
Yes.  Thanks.