Re: Steps with non-connected outputs

/ Alex Milowski <alex@milowski.org> was heard to say:
| In my model, we have the following time sequence for the lifetime of
| a step:
|
| 1. Initialization of the component happens.  This is typically while the
|    pipeline itself is being initialized.  This is a event that probably
| happens
|    outside our specification.
|
| 2. Resources that are statically known and bound to input ports are made
|    available to  steps.  This allows steps to detect errors staticially (
| e.g. I can't
|    locate or compile the XSLT transform).  This is an optimization but a
| very
|    important one.
|
| 3. Output ports are bound to their recipients.
|
| 4. The pipeline starts and the step is notified.
|
| 5. Some sequence of documents are received (or "pulled") on the
|    input ports for the step.
|
| 6. The pipeline ends and the step is notified.
|
| I think our specification needs to allow for 1-3 but needs to focus on
| 4-6 as standard semantics.

That is waaayyyy more than we want to say. Or at least, it's way more
than *I* want to say. I think it's something like this:

1. Initialization of the component happens.

Clearly outside our scope.

2. The pipeline starts running.

Well, duh, how else is anything ever going to happen.

3. Each step is run. Steps that occur inside for-each may run more than
   once.

4. Each step reads as much of its input as it wants. There's no
   gaurantee that all input is avialable when execution begins. Steps
   may have to block waiting for input. There's no gaurantee that all
   steps read all their inputs.

5. Steps produce their output, if any.

6. Each step stops.

7. The pipeline stops.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.