Re: Side effects and interoperability

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| I therefore think it's vital that if the pipeline language doesn't
| constrain a pipeline engine to run two steps in a particular order
| then the order in which the two steps are run doesn't have an effect:
| the steps have no side effects.

I agree.

Clearly, in this pipeline:

  A => B

the output from A flows to B so A has to run before or at the same
time as B.

In this pipeline:

  C => D => +---+
            | G |
  E => F => +---+

there's no constraint on the order in which C and E are run so it
shouldn't matter.

I think we've identified one class of side-effects that we have to
consider: auxilliary outputs. Suppose C produces module.xsl which
E consumes (in an xsl:include).

We could model this as an output from C flowing into E. But that might
not be convenient. For one thing, the xsl:include statement is
probably going to be processed by the XSLT module which will attempt
to grab it by URI. In this case, if we know there's a resource manager
involved, we can be sure that it returns the right thing.

If there isn't a resource manager involved, then as long as we make
sure that C runs to completion before E starts, we can assume that
module.xsl will have been written and the right thing will happen.

I think we can model this with "auxiliary" inputs and outputs.

  C => D => +---+
  |         |   |
  |         | G |
  v         |   |
  E => F => +---+

As far as I can see, this gives the graph enough information to
determine the order in which steps must be evaluated. In this case,
there's still no dependency between D and F so it shouldn't matter
what order they're processed in.

In short:

1. I propose that we adopt some mechanism for identifying auxiliary
   inputs and outputs

2. With that addition to the flow graph in place, I propose that we
   assert that processors are side-effect free.

                                        Be seeing you,
                                          norm

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