# Some glitches in process definitions

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Mon, 18 Oct 2004 12:34:48 +0000 (GMT)

Message-ID: <E1CJWjR-0000cN-W4@frink.w3.org>


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:13 UTC