- From: Alessandro Vernet <avernet@orbeon.com>
- Date: Wed, 26 Apr 2006 12:42:21 -0700
- To: public-xml-processing-model-wg@w3.org
Norm, A parallel can be made between the pipeline language, and other programming languages that have a concept of function. Components can be compared to functions, and a steps to function calls. With this in mind, let's look 2 piplines. 1) First pipeline: main = <doc/> t1 = timestamp() t2 = timestamp() t3 = timestamp() result = append(main, t1, t2, t3) I think it is reasonable to expect a result like: <doc> <t>43151</t> <t>43153</t> <t>43159</t> </doc> 2) Second pipeline: main = <doc/> t = timestamp() result = append(main, t, t, t) Here there is only one steps that uses the timestamp component and the output of this step is used 3 times. In this case, I will expect the result to look like: <doc> <t>43151</t> <t>43151</t> <t>43151</t> </doc> I don't see the benefit of saying that if timestamp is called multiple times, it has to always return the same result. If the authors goes through the trouble of writing multiple calls to the same component (as in pipeline 1 above), it is likely that he wants that step to run multiple times. Alex On 4/20/06, Norman Walsh <Norman.Walsh@sun.com> wrote: > Here's an example of the pipeline I had in mind on the call today. It > contains only two components: Append and Timestamp. > > Append takes two inputs, main and new, and appends them. For example: > > main = <p><foo/></p> > new = <bar/> > append = <p><foo/><bar/></p> > > Timestamp takes no inputs and has no parameters. It returns a document > containing the time of day in seconds. For example: > > = <t>43151</t> > > What is the output from this pipeline: > > <p:pipeline> > <p:output label="foo"/> > > <p:step name="p:timestamp"> > <p:output label="t1"/> > </p:step> > > <p:step name="p:append"> > <p:input name="main"> > <doc></doc> > </p:input> > <p:input name="new" select="$t1"/> > <p:output label="a1"/> > </p:step> > > <p:step name="p:timestamp"> > <p:output label="t2"/> > </p:step> > > <p:step name="p:append"> > <p:input name="main" select="$a1"/> > <p:input name="new" select="$t2"/> > <p:output label="a2"/> > </p:step> > > <p:step name="p:timestamp"> > <p:output label="t3"/> > </p:step> > > <p:step name="p:append"> > <p:input name="main" select="$a2"/> > <p:input name="new" select="$t3"/> > <p:output label="$foo"/> > </p:step> > > </p:pipeline> > > I contend that it makes sense for us to be able to annotate whether or > not components have side effects. If the Timestamp component has such > an annotation then the output will be something like: > > <doc> > <t>43151</t> > <t>43153</t> > <t>43159</t> > </doc> > > If the Timestamp component has no such annotation (or asserts that it > doesn't have side effects) then that could still be the result > (implementations aren't required to cache results). But this would be > an equally valid result: > > <doc> > <t>43151</t> > <t>43151</t> > <t>43151</t> > </doc> > > I think Alex wants the pipeline to express this in some way through > dependencies, but that strikes me as terribly awkward for the poor > user: > > <p:pipeline> > <p:output label="foo"/> > > <p:step name="p:timestamp"> > <p:output label="t1"/> > <p:output href="http://example.org/randomuri1"/> > </p:step> > > <p:step name="p:append"> > <p:input name="main"> > <doc></doc> > </p:input> > <p:input name="new" select="$t1"/> > <p:input href="http://example.org/randomuri1"/> > <p:output label="a1"/> > </p:step> > > <p:step name="p:timestamp"> > <p:output label="t2"/> > <p:output href="http://example.org/randomuri2"/> > </p:step> > > <p:step name="p:append"> > <p:input name="main" select="$a1"/> > <p:input name="new" select="$t2"/> > <p:input href="http://example.org/randomuri2"/> > <p:output label="a2"/> > </p:step> > > <p:step name="p:timestamp"> > <p:output label="t3"/> > <p:output href="http://example.org/randomuri3"/> > </p:step> > > <p:step name="p:append"> > <p:input name="main" select="$a2"/> > <p:input name="new" select="$t3"/> > <p:input href="http://example.org/randomuri3"/> > <p:output label="$foo"/> > </p:step> > > </p:pipeline> > > Surely it makes more sense to just allow the component to be > identified as unstable. > > > Be seeing you, > norm > > -- > Norman Walsh > XML Standards Architect > Sun Microsystems, Inc. > > > -- Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/
Received on Wednesday, 26 April 2006 19:42:34 UTC