RE: choose is poorly and/or incorrectly specified

> 
> The description of p:choose says:
> 
>   The outputs of the p:choose are taken from the outputs of the
>   selected subpipeline. The p:choose has the same number of outputs as
>   the selected subpipeline with the same names. 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.
> 
> This is followed later by Example 7 which reads, in part:
> 
> <p:choose name="version">
>   <p:when test="/*[@version = 2]">
>     <p:validate-with-xml-schema>...
>   </p:when>
> 
>   <p:when test="/*[@version = 1]">
>     <p:validate-with-xml-schema>...
>   </p:when>
> 
>   <p:when test="/*[@version]">
>     <p:identity/>
>   </p:when>
> 
>   <p:otherwise>
>     <p:output port="result">
>       <!-- this output is necessary so that all the branches have
>            the same outputs; it'll never really matter because
>            we're just about to raise an error. -->
>     ...
> 
> The comment in the otherwise suggests that the preceding p:when
> statements have an output named result. This is partially supported
> by section 2.3:
> 
>   Additionally, if a compound step has no declared outputs and the
>   last step in its subpipeline has an unbound 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 bound to it).
>   This implicit output port has no name. It inherits the sequence
>   property of the port bound to it.
> 
> Except that 2.3 says the implicit output port has no name.
> 
> Bleh.
> 
> I'm tempted to change 2.3 to say that the implicit output port is
> named "result". Either that, or our example has to be changed so that
> every p:when explicitly declares an output named result.
> 

One note: p:choose is a multi-container step, not a compound step in the
traditional sense. I would therefore say that the text in section 2.3
does not apply to p:choose (and p:try as well)?

Personally, I don't like giving the implicit output port a name. Of
course, we have done this with p:pipeline ("source", "result") and
p:viewport/p:for-each ("current"), but these cases seem a bit different
to me to what you are proposing. I am afraid that giving the implicit
output port of a compound step a name might introduce lots of confusing
'magic' in XProc code...

Regards,
Vojtech

Received on Thursday, 2 April 2009 07:53:22 UTC