How to make progress on resolving abstract process syntax and semantics

["Satish Thatte" <satisht@microsoft.com>]

My thought is that at a *technical* level, abstract processes will be
exactly partially specified processes.  I don't see the chance for any
other outcome at a technical level at least for the current version of
BPEL.  There are four specific issues that need to be resolved to make
this more meaningful.  In the order of priority and dependence, they
are:

1.  What use cases do we take as essential requirements for partially
specified processes?  My suggestion is that we take external or public
view of behavior of a single process (participant) as the only canonical
and essential use case.

2.  What does "partial" mean?  In other words, which syntactic elements
are allowed to be left out and which other rules relaxed?  Are there
syntactic elements that are forbidden in abstract processes? This will
clearly be dictated by 1.  

3.  What is the *meaning* of conformance between an abstract process as
a public view and the corresponding private executable process?  This is
a precise "mathematical" relationship that needs to be well-defined in
all cases but does *not* need to be algorithmically decidable.  This
cannot be addressed without resolving 2.

4.  What is the syntactic device for omitted elements in partially
specified processes?  For instance, simple textual omission vs explicit
<opaque> marking.  I believe this will be dictated by the answer to 3.

I would suggest we focus on these four issues at the F2F.

Satish