Compound steps referring to themselves?

[vojtechtoman]

Editor's Draft 10 June, section 2.5 (Connections:)

Within the context of a compound step, the declared outputs of the compound step must describe their connections. The set of possibilities for this connection is exactly the same set as for any other input port within the current environment.

Maybe I am reading this wrong, but does the last sentence mean that, for example, an output port of p:for-each can connect to the p:for-each's current input port?

[ndw]

Yes. You can pass an input through to an output. It's weird, but it's allowed, I believe.

[ndw]

Are you satisfied with that answer? Can we close this issue?

[vojtechtoman]

What about 'empty' compound steps such as this one (I actually think this could be quite useful):

<p:declare-step type="ex:duplicate" name="duplicate">
  <p:input port="source"/>
  <p:output port="result" sequence="true">
    <p:pipe step="duplicate" port="source"/>
    <p:pipe step="duplicate" port="source"/>
  </p:output>
</p:declare-step>

Will things like this be supported? (Similar for p:pipeline, p:for-each, etc. if the subpipeline is made optional.) If so, then I think the definition of an atomic step should be revisited because:

An atomic step is a step that performs a unit of processing on its input, such as XInclude or transformation, and has no internal subpipeline.

will no longer be true.

[ndw]

The subpipeline isn't currently optional. Are you proposing that it should be? I think that having an output of a compound step simply copy one of the inputs is a rare edge case. Prohibiting it doesn't seem necessary, though I probably wouldn't be strongly opposed, but it also doesn't seem like something we need to be encouraging exactly.

The non-edge case version is:

<p:declare-step type="ex:duplicate" name="duplicate">
  <p:input port="source"/>
  <p:output port="result" sequence="true"/>
  <p:identity>
    <p:pipe step="duplicate" port="source"/>
    <p:pipe step="duplicate" port="source"/>
  </p:identity>
</p:declare-step>

Which works for me.

[vojtechtoman]

No, I am not proposing to make the subpipeline optional. I think it is too big of a change to justify the few edge cases. I was trying to understand if the current 'compound steps referring to themselves' story is consistent with the rest of the spec. It seems to be, and as long as the example in my previous comment causes err:XS0029 I believe things are fine.

So I think you can close this as a non-issue.

[ndw]

Thanks.