Re: Execution order of steps in a pipeline

/ Toman_Vojtech@emc.com was heard to say:
| I have a question about evaluating the steps of a pipeline. Section 2
| says:
|
| "The result of evaluating a pipeline (or subpipeline) is the result of
| evaluating the steps that it contains, in an order consistent with the
| connections between them. [...]"
|
| I am sure this has been asked before (even though I could not find any
| discussion about this topic), but is this really necessary? Why cannot
| the execution of the contained steps just follow the document order?

Mostly because doing so would put an unnecessary burden on pipeline
authors. (Implementors wouldn't benefit from the change because they'd
have to check all the connections anyway.)

Consider a pipeline that contains a linear sequence of steps where one
of the steps is an XSLT step:

  <px:one/>
  <px:two/>
  <p:xslt>
    <p:input port="stylesheet">
      <p:pipe step="generator" port="result"/>
    </p:input>
  </p:xslt>
  <px:three/>
  <px:four/>

Why should the pipeline author be required to place the step named
"generator" before the p:xslt step?

The status-quo gives pipeline authors freedom to organize their steps
in a manner that's convenient for them.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | What is more wonderful than the delight
http://nwalsh.com/            | which the mind feels when it *knows*?
                              | This delight is not for anything beyond
                              | the knowing, but is in the act of
                              | knowing. It is the satisfaction of a
                              | primary instinct.--Mark Rutherford