Re: A side-effect example

/ Alex Milowski <alex@milowski.org> was heard to say:
| The second flow graph uses three separate "sub-steps" where each output
| is appened to the current input document of the append step. 

That's the graph I had in mind.

| From my
| perspective, those are still three separate steps and so there are three
| different results.

But the input to the timestamp component is the same every time, so
the open question is (was?) whether or not the engine was free to
cache the results.

| If those sub-steps were sub-pipelines, you could
| argue that they should produce the same result.

I thought (am hoping) that p:pipeline is a component that is
interchangable with other components, so I don't see how it would
matter if I wrapped each p:timestamp in a p:pipeline.

| In the third example, the same step is shared amongst three append
| steps.  Here we have to decide on whether there is *caching* of results,
| separate invocations, or user control of either behavior.

No, I disagree. In this example, the timestamp component has three
outputs. What those outputs are is the responsibility of the
component. If timestamp has only one output, then you need additional
p:tee components in there to make the pipeline sensible.

| In all these examples, I don't see side-effects other than the question
| of stable results.

Agreed.

| Analogous to the document() function in XSLT, an issue for us is
| whether flow graph 2 works the same when the output is labeled by a URI.
| That is, is the document to URI mapping stable throughout the pipeline
| execution?

I'd like to think so.

                                        Be seeing you,
                                          norm

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