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

[rkhalaf <rkhalaf@watson.ibm.com>]

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.

Regards,
Rania.

Monica J. Martin wrote:
> Proposed suggestions or clarifications sought for Issue 82:
> 
> ============================================================================================================== 
> 
> 
> 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.
> 

   RK>> +1

> 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. I would separate the concepts 
> explicitly between a) the core AP definition [1], b) profiles, and c) 
> Any profile we give as an example such as AP v1.1.
> 

   RK>> Splitting into three sections makese sense.   If the base 
becomes a profile, then it follows that there would be an additional 
small section for that as another example profile.  Does this discussion 
really belong to 158?

  RK>> Regarding the base as guiding principle though, in the voted 
proposal the base was defined as  "a set of basic, minimal requirements 
(base) for all abstract processes".  Are you proposing to change that ?

> [1] Concentrate on lightweight, template-like semantics recognizing 
> abstract processes are incomplete, could include opaque entities and may 
> serve as the basis
> of creation of an executable process through various means.
> 

   RK>> Why concentrate on light-weight, template-like semantics ? The 
current text allows multiple use cases without preference, and 
specifically point out templating. Perhaps I misunderstand the intent?
   RK>> +1 on the second half of the sentence "Abstract process are 
incomplete ... means "

> 3. Link Issue 82 to 158 to resolve the construction of the specification 
> and leave it that except to say that the document construction will be 
> handled before Issue 82 can be fully closed (dependency). [2]
> 

    RK>> The voted proposal because already addresses the relation to 
issue 158.
   (From the minutes and Peter's revised resolution, the relation issues 
158 was: "The structure of the ultimate specification and how many 
documents there will be will be left open and dealt with as part of 158.")

> [2] The abstract process definition should keep Issue 158 on track.
> 
> 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.

    RK>> +1 I believe this was the agreement as well. Great for the 
group to have a stable thing to work off of.

> 
> 5. Other specific changes:
> 
> Change From [letter such as 'a'] / Change To [letter such as 'a1']:
> 
> Note: Clarifications identified as such.
> 
> 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'.
> 

   RK>> Is this to allow an abstract process that can be made into an 
exec and back just by changing the value of the abstractProcess 
attribute ? That is to address the problem that currently the sentence 
(a) above from Peter's text seems to contradict with his point [1] 
("Although it might contain complete information that would render it 
executable as specified for executable BPEL, ...").

> 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 can define the publicly 
> visible behavior of all of the services it offers....
> 

   RK>> Good catch.  How about "the visible behavior of the services it 
offers?" . I think both of the other two are confusing.

> Reasoning: The use of 'some" because it confuses an example of 
> description of an example of use. From a reference from Peter Furniss, 
> an abstract process could refer to only one service of something that 
> has executables that offer multiple services - one could have a 
> customer-facing link, defined by the abstract process, and a management 
> link that wasn't in that abstract process (but might be in another one 
> that also mapped to the same executable).
> 
> 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) by enterprises and vertical 
> standards organizations.
> 

   RK>>  please clarify.

> 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. Executable 
> processes have well-defined semantics that may not be relevant, visible 
> or exposed in a base or profiled abstract process definition.
> 

   RK>> (d1) removes a major substantive part of (d): that the semantics 
of the base alone are ill-defined and where they come from.  The 
reasoning for (d) is due to how loose the base is, reasonable 
assumptions cannot be made about many of the constructs if they are 
missing pieces (some emails detailing this are in the mailing list).

   RK>>  This seems to be not intuitively obvious from (d) alone. 
Perhaps it would help to add examples of why the semantics of the base 
alone are ill-defined ?


> Reasoning: The semantics could be indicative (even if implicit) of the 
> profiled domain.  Assumptions may be made because of the use of BPEL 
> constructs or what can replace opaque or missing entities (such as 
> suggested by Peter).
> 
> 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.
> 

    RK>> The last sentence in (e1) is easier to swallow than the  old 
one. I like it. I'm not sure though wether the first sentence drops the 
phrase, "it could be mapped to". I assume that the phrase is still there 
due to (....).

> 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.
> 

    RK>> This was a major point of contention and was split off of 82. 
How should we handle this and the other points left open as part of the 
82 vote ? open a new issue so we have a parallel with 158 ?

> 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. The semantics and consistency constraints of executable BPEL are 
> clearly defined. The semantics of each construct in an abstract process 
> MAY BE derived from that of the same construct in executable BPEL.
> 


> Reasoning: Given the fact we can add constructs, is it actually true 
> that the semantics of the abstract ARE ALWAYS derived from the 
> executable? Some of the executable process constraints will not apply to 
> specific abstract process instances, depending on what is abstracted 
> out. Therefore, MAY is an appropriate qualifier.
> 

  RK>> Ooh I see. But we still need to say that the ones that do come 
from exec (as opposed to additions like "opaque") are always derived 
from there. How about "The semantics of each construct in an abstract 
process that comes from the syntax of executable processes is are always 
... "   ?

> 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.
> 

   RK>> There is a misunderstanding here I think. The idea of (h) is 
that there will be a schema that is identical to the exec schema but 
also allow opaque activities, attributes and expressions. Using this 
schema, one can validate an abstract process on its own without caring 
about executable processes. For attributes and expressions that are 
omitted, see end of Peter's [3] on omission and replacement with opaque.

> Reasoning: What happens when we have an opaque entity and it is not 
> replaced in an executable process? Even if the abstract and executable 
> are syntactically valid individually, can we also always say the 
> abstract is syntactically valid to the executable? Abstract process 
> syntax alters executable process syntax in at least two ways:
> 
>    * Addition of opaque activities and attributes
>    * Relaxation of cardinality constraints
>  From this strictly syntactic point of view, Ron and I can't see how an 
> AP can be required to be EP schema valid, with or without the addition 
> of opaque entities.
> 
> 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.

    RK >> +1

> 
> 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. Clarify: How can we deny the existence of AP semantics, but only 
> acknowledge the semantics of resulting EPs?

   RK>> Yes, in the spec we should summarize some of the discussions on 
e-mail that led to having this in the proposal.