Some glitches in process definitions

In our latest attempts to finish the process formalism for Owl-S,
there are a couple of issues that we have to address:

(1) The "ParentPerform" entity seems unnecessary to me.  I would have
   to work to get my surface-syntax parser to deal with it.  After
   staring at this problem for a while, I fudged the output of the
   parser to include this thing, but I don't see the need for it.  For
   one thing, it's misleading.  The ParentPerform is the actual
   process instance we're describing, not its parent.  For another,
   the ParentForm has no independent motivation for existing.  There's
   nothing we can say about it; it's just there so a parameter called
   I1 is always used as a parameter and never as a variable.

   I propose that we do what standard programming languages do: within
   a process definition, allow references to the inputs and outputs of
   that process as ordinary symbols.  The only obstacle is the 
   XML scoping rules, which require a name to denote the same thing
   everywhere.  The solution is to introduce a new property (e.g.,
   'localName') for parameters.  Any reference to a parameter of the
   current process in the surface syntax would get translated to a
   reference to its localName in the XML/RDF syntax.

(2) In the most recent draft of the technical overview of processes, I
   introduced a pseudo-control-construct called 'Produce'.  Its
   purpose is to link output parameters of the current process to
   their values, as in this tableau (from the technical-overview
   draft):

    define composite process CP(inputs: (I1),
				outputs: (O1))
      {
       step1 :: perform S1(I11 <= Incr(I1), I12 <= "Academic");
       step2 :: perform S2(I21 <= step1.O11);
       produce (O1 <= pi * max(0, step2.O21))
      }

   The last line says "The output O1 of the process [CP] is \pi times
   the max of 0 and the o21 output of step2."  We have to have
   something like this because the outputs of the process depend on
   the flow of control through the process, so that an alternative
   such as declaring the outputs in the header would be unworkable. 

                                                -- Drew


-- 
                                             -- Drew McDermott
                                                Yale CS Department

Received on Monday, 18 October 2004 12:35:22 UTC