Re: [wsbpel] Issue 82 - Proposed resolution for vote (revised)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

> Khalaf: Hi Monica,
> Hope you had a good new year's ;)
>
> You make good points. I have added my comments to each point below 
> (starting with RK>> ).
> I think as long as we maintain your point (4), this issue will finally 
> be able to continue and conclude in a happy healthy way.
> Looking forward to more discussions.

mm2: Sorry for a bit of delay...coordination. Friday would work for Ron 
and I to meet via phone.  I am available that day (1/28/2005) between 
9-10 a.m. EST
and 12 noon-2 p.m. EST.  I think this fits in the times you specified 
and hopefully would work for Peter (at least the earlier time anyway). 
Here are some updates and identified areas that may warrant more 
discussion, including answers to some of your  questions Rania.

Thank you.
===========================================================================================================
(**) Changed

1. Emphasis that a profile created from the abstract process assumptions 
in v1.1 is an example of how to constrain or build from the base. It is 
not the base.

2. **For statement: "Every AP instance will always refer to a profile 
URI to define its meaning." I would suggest we concentrate on the core 
AP definition as a guiding principle. If it needs the visibility as a 
profile to do so, so be it.  I would separate the concepts explicitly 
between a) the core AP
definition [1] [2], b) profiles from the base abstract definition, and 
c) Any profile we give as an example. For those profile included in the 
specification, the AP v1.1 could be one such profile example.

**[1] Add: The base is a set of minimum requirements for all abstract 
processes.
**[2] Add: If the base becomes a profile, it will be included as another 
example profile.

**Additional clarification:  The semantics should be lightweight and 
focused on enabling the profiles that may be defined. This lightweight 
nature recognizes that abstract processes are incomplete, could include 
opaque entities and may serve as the basis of creation of an executable 
process through various means.
Note: The dependency between Issue 158 and 82 exists to support all 
these goals.

3. **Create a dependency between Issue 82 to 158. Issue 158 SHOULD not 
be allowed to close until Issue 82 does.

**Response: The abstract process definition should keep Issue 158 on 
track.  Issue 158 is essentially editorial, and the structure of the 
spec (as decided by the resolution of 158) should reflect the structure 
of the abstract language (as decided in 82).

4. Ambiguities should be limited/focus on non-substantive changes to the 
accepted concept,  i.e. editorial comment, further clarification that do 
not change the substance of the accepted proposal, which I believe was 
the agreement.

5. Other specific changes:

Change From/Change To:

a. Whereas executable processes are fully concretized and thus can be 
executed, an abstract process lacks some of the required concrete 
operational details expressed by or when mapping it to a fully 
executable artifact. An abstract BPEL process must be explicitly 
declared as 'abstract'.
a1. Whereas executable processes are fully concretized and thus can be 
executed, an abstract process MAY lack some of the required concrete 
operational details expressed by a fully executable artifact. An 
abstract BPEL process MUST be explicitly declared as 'abstract'.

**Response: This is to clarify a contradiction in the abstract 
definition for Issue 82. An abstract process could be executable, by 
simply changing the value of the abstractProcess attribute, in direct 
response to your question.

b. Abstract processes serve a descriptive role, with more than one 
possible purpose. A BPEL abstract process can define the publicly 
visible behavior of some or all of the services it offers....
**b1. Abstract processes serve a descriptive role, with more than one 
possible purpose. A BPEL abstract process MAY define the visible 
behavior of all services it offers....

**Additional clarification: See revised text above. We in essence may 
have a black-box but only the box rim is showing. You could have 
explicit opaque entities (whatever they are) but don't know any details.

c. The process "template" captures some essential process logic while 
leaving out operational details that will be concretized by the 
enterprises and vertical standards organizations when mapping the 
partial process specification to a fully executable artifact.
**c1. The process "template" captures some essential process logic while 
leaving out operational details. These details MAY be concretized in 
resulting fully executable artifact(s).  An example could be the 
combination (or even separate) of roles, such as a self-insuring shipper.

**Response: Grammatically, the original was a run-on sentence. On second 
thought, many organizations may go from from one abstract to many 
executable.
We would prefer we are generic. I don't know if we gain anything in the 
original text. I could see that an abstract process may be further 
refined into another abstract process. The first one may not every 
become executable although the refinement may. A good example would be 
the combination (or even separate) of roles, such as a self-insuring 
shipper.

d. From this base, "usage profiles" can be defined. On its own, the base 
lacks well-defined semantics - the only constructs that have defined 
meaning are the constructs of executable processes, and that meaning is 
defined by prescribed behavior of the executable process as a whole, and 
is thus not
directly available outside an executable process.
**d1.  From this base, "usage profiles" can be defined. Abstract 
processes lack well-defined semantics. Conversely, executable processes 
have well-defined semantics and prescribed behavior. Those executable 
process semantics MAY not be relevant, visible, available or exposed in 
the base abstract process definition or a profile.

**Response: See revision. I think we make it quite clear in the abstract 
definition and through the spec about executable processes. This allows 
us to be less verbose here. An example would be helpful here, I agree.  
Rania/Peter, we can discuss what semantics you have in mind in order to 
resolve the difference.

e. The semantics of an abstract process are therefore derived from those 
of the executable process it could be mapped to.....An abstract process  
MUST identify the usage profile  that defines its meaning with a URI. 
Profiles may be defined by anyone - in separate standardization efforts, 
internally in organizations or for proprietary usage, etc.
e1.  The semantics of an abstract process are therefore derived from 
those of the executable process....An abstract process  MUST identify 
the usage profile  that defines its meaning with a URI. Profiles may be 
defined outside of this specification.

**Response: The phrase "it could be mapped to" seemed redundant to the 
fact that it is derived from an executable process.

f. It is left open, at the moment, whether the base definition itself is 
to be considered as a profile. If it is, it will be assigned a URI to 
identify it.
**f1. The base definition is considered as a profile. When used, it will 
utilize the URI assigned to it.

**Response: Suggest we break off as a separate issue linked to Issue 82 
and 158 with the same cross-dependencies.

Semantics of Abstract Processes:
g. The semantics and consistency constraints of executable BPEL are 
clearly defined. The semantics of each construct in an abstract
process are always derived from that of the same construct in executable 
BPEL.
**g1.An abstract process syntactic construct derived from a 
corresponding executable BPEL construct MUST assume the semantics of 
that executable process.

**Response: Deleted first sentence as it is redundant to preceding text 
in previous details. May require additional discussion in order to 
verify we are saying what we mean. :>)

h. Additionally, an abstract process is required to be syntactically 
valid using the executable schema extended with the opaque entities.
**h1. Additionally, an abstract process is required to be syntactically 
valid. The abstract process schema will be syntactically consistent with 
the executable
one while details MAY be omitted and opaque entities MAY be defined.

**Response: Rania/Peter, we need to preserve both parts of the abstract 
process definition:
(1) An abstract process is an executable one with some details omitted
(2) An abstract process is an executable one with opaque entities added.

j. [4] In this base definition, to avoid absurd constructs and to 
clarify opacity, the minimal requirement is that for any abstract
process, there exists at least one syntactic completion that yields a 
*valid executable process* by
   a) replacing each opaque token by a concrete entity or removing the 
opaque token completely, and
   b) adding new BPEL XML elements anywhere in the process.
j1. Clarify: This is used for schema validation on an abstract process 
not for process semantics.

k. [6] Abstract processes are *incomplete* and non-executable by 
definition, whether or not they contain opaque entities. Therefore
the semantics of the non-opaque constructs they contain cannot be 
understood in isolation from the relationship of the abstract
process with the executable *completions* it permits. The reason being 
that the semantics of those constructs actually exists only
in the possible executable completions. As an edge case, a permitted 
completion may sometimes be identical to the abstract
process syntactically, but this is the exception rather than the rule.
**k1. TBD

**Response: Without some explanatory text, this is confusing. In this 
issue, we have described the derivations, the relationship in semantics, 
and the syntactic assumptions between executable and abstract processes. 
The completeness of executable processes is also detailed in the 
specification and herein. I am uncertain this text adds sufficient value 
except to specify the edge case to bring some of the other previous 
statements into perspective.
Given these assumptions, recommend we only cite the edge case as 
everything else is already defined elsewhere.