Produce construct worries

I have some concerns about the Produce construct, which was a late 
addition to OWL-S 1.1.

If I have understood things correctly, the purpose of Produce is to bind 
outputs of the parent composite process from one of its children. This 
is necessary if the children are executed conditionally (i.e. the 
composite process is an If-Then-Else, Repeat-Until, or Repeat-While) 
since these bindings will depend on which subprocess gets executed, and 
this is not known until runtime. Therefore, the bindings can not be put 
in the parent composite process.

BUT, I don't like the solution of introducing a new control construct 
for this, for several reasons:

1) It seems like overkill. With Produce, we often need TWO additional 
construct, because adding a Produce after another construct means that 
both construct will have to be put inside a Sequence construct (unless 
there is already a Sequence).

2) Produce differs from all the other constructs in that it is a pure 
"client-side" operation, whereas all the other ones are essentially 
"server-side".

3) Produce is not an independently executable unit, but depends on 
another construct (the source of the parameter to bind) for its 
functionality. This could also be said of e.g. Repeat-Until, which 
depends on its untilProcess, but in this case the relationship is made 
explicit by the untilProcess property. There is no corresponding 
property in Produce to make the relationship explicit. Furthermore, if 
there was such a relationship, it would break with the structure of 
OWL-S composite processes always being trees with Performs at the leaves.

4) It is difficult to model composite processes with Produce. In our 
OWL-S Editor (under construction) we can model all other control 
constructs in a very straightforward way, but it's hard to see how to 
handle Produce in any intuitive way graphically.

5) And finally, it does not seem to me that it is really needed. The way 
Produce works is that it has a property producedBinding, which takes an 
OutputBinding. Why not just change the domain of producedBinding from 
Produce to Perform, and thus declare these OutputBindings at the Perform 
itself, rather than in an extra unwieldy Produce control construct? All 
Performs would declare their own OutputBindings, so the fromProcess 
property of the OutputBinding would always be ThisPerform. This seems 
much more straightforward to me.

Cheers,
/Daniel

Received on Tuesday, 23 November 2004 23:24:32 UTC