Re: choose is poorly and/or incorrectly specified

Toman_Vojtech@emc.com writes:
> 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)?

Uhm. Ok. I'm not sure I want to go there, but let's say we do. We still
have a problem.

The paragraph after the one I previously quoted in 4.4 p:choose is:

  In order to ensure that the output of the p:choose is consistent
  irrespective of the subpipeline chosen, each subpipeline must
  declare the same number of outputs with the same names and the same
  settings with respect to sequences. If any of the subpipelines
  specifies a primary output port, each subpipeline must specify
  exactly the same output as primary. It is a static error
  (err:XS0007) if two subpipelines in a p:choose declare different
  outputs.

Example 7 manifestly raises err:XS0007:

  ...
  <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. -->
      <p:inline>
        <nop/>
      </p:inline>
    </p:output>
    <p:error code="NOVERSION">
      <p:input port="source">
        <p:inline>
          <message>Required version attribute missing.</message>
        </p:inline>
      </p:input>
    </p:error>
  </p:otherwise>
  </p:choose>

Because the p:when subpipelines all have an anonymous output and the
p:otherwise has an output named "result".

I guess I could rewrite my otherwise like this:

  <p:otherwise>
    <p:error code="NOVERSION">
      <p:input port="source">
        <p:inline>
          <message>Required version attribute missing.</message>
        </p:inline>
      </p:input>
    </p:error>
    <p:identity>
      <p:input port="source">
        <p:inline><doc>this can never happen</doc></p:inline>
      </p:input>
    </p:identity>
  </p:otherwise>

Does that work? I think it does.

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

Fair enough. Maybe now that I've cooked up a workaround, I'm less
freaked out.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | In every work of genius we recognize
http://nwalsh.com/            | our own rejected thoughts; they come
                              | back to us with a certain alienated
                              | majesty.-- Emerson