then we were at different meetings:-)
at least we understood differently.
Im really confused as from the below there appear to me to be
contradictions:
>We had agreement that mandatory extensions was intended to be
>the primary usage case for the <opaque> activity/expression
>proposal, as I wrote below.
and
>>The purpose of <opaque> is NOT to specify all
>>allowable points of extension, prohibiting all other potential
>>points of extension in the completion of an abstract process.
>>Secondarily, <opaque> activities and expressions serve as a
>>convenience for technical specification and validation using a
>>single schema.
the first says mandatory and the second implies optional to me.
>-----Original Message-----
>From: Satish Thatte [mailto:]
>Sent: 20 July 2004 21:51
>To: Martin Chapman;
>Subject: RE: [wsbpel-abstract] Potential requirements and use case
>
>
>That was not my understanding.
>
>We had agreement that mandatory extensions was intended to be
>the primary usage case for the <opaque> activity/expression
>proposal, as I wrote below. We need to discuss whether that
>is something which we should support based on the range of
>usage scenarios in which it is relevant. I argued below that
>the usage scenarios are narrow.
>
>Do you agree with my characterization of the usage scenarios?
>
>Satish
>
>-----Original Message-----
>From: Martin Chapman [mailto:]
>Sent: Tuesday, July 20, 2004 12:46 PM
>To: Satish Thatte;
>Subject: RE: [wsbpel-abstract] Potential requirements and use case
>
>Satish,
>
>I thought on Friday we had tentative agreement that opaque
>should be part of (abstract)
>BPEL to identify mandatory extension points, but its use is optional.
>
>
>Martin.
>
>>-----Original Message-----
>>From: Satish Thatte [mailto:]
>>Sent: 16 July 2004 17:48
>>To:
>>Subject: RE: [wsbpel-abstract] Potential requirements and use case
>>
>>
>>I think we are agreeing on a few things
>>
>>1. abstract BPEL allows partial specification of executable processes.
>>
>>2. we need a precise definition of conformance between a
>>partial process and any executable process that claims to be
>>its completion
>>
>>3. We do not want to preclude any use case for abstract
>>processes, including
>>
>>a. A notation for specifying the externally visible behavior
>>of a web service or a collection of web services where the
>>notation may be used with various degrees of austerity as
>>appropriate for the needs of the specifier,
>>
>>b. A notation for exchange of process requirements across
>>autonomous entities where the abstract and the executable
>>process are NOT "owned" by the same entity, and
>>
>>c. A notation for partial specification in a modeling context
>>where the abstract and the executable process ARE "owned" by
>>the same entity.
>>
>>4. <opaque> activities and expressions are primarily intended
>>as a proposal for allowing the designer of an abstract process
>>to express his/her intentions regarding mandatory points of
>>extension. The purpose of <opaque> is NOT to specify all
>>allowable points of extension, prohibiting all other potential
>>points of extension in the completion of an abstract process.
>>Secondarily, <opaque> activities and expressions serve as a
>>convenience for technical specification and validation using a
>>single schema.
>>
>>I would argue that the technical convenience argument for
>><opaque> is a weak one because the syntactically mandated
>>completion points can be easily found by tools and forcing an
>>abstract process designer to explicitly design them in helps
>>tools and BPEL specification writers at the expense of the
>>users of abstract BPEL, i.e., those who read and write
>>instances of abstract BPEL. This is especially the case for
>>use case (a) above where brevity and readability are likely to
>>be very important.
>>
>>I believe the primary intention of the <opaque> proposal as a
>>mechanism for expressing the intention for mandatory extension
>>applies primarily to use case (c) and as such I would argue
>>that it belongs more in the realm of a tools oriented
>>extension rather than an essential aspect of abstract BPEL.
>>
>>Satish
>>
>>
>>________________________________________
>>From: Satish Thatte
>>Sent: Thursday, July 15, 2004 10:20 PM
>>To:
>>Subject: RE: [wsbpel-abstract] Potential requirements and use case
>>
>>I would add that in real scenarios external views are often
>>linked with modeling requirements. A large company may
>>specify a "required external view" in the form of an abstract
>>process for its partners' processes without dictating how such
>>a process is completed by the partners. The partners may need
>>to take their required external view and use it as input into
>>a modeling environment for completion and implementation in
>>their own environments. However, it is extremely unlilely
>>that the large company will dictate exactly how the process is
>>to be completed by specifying the exact places where it must
>>be extended. Each partner may of course complete and
>>implement the process differently, so long as all maintain the
>>externally visible contract specified by the abstract process.
>>
>>We would therefore be better off specifying the base techical
>>notion of abstract processes as partial processes and we
>>should avoid attempts to narrow the space of use cases artificially.
>>
>>Satish
>>
>>________________________________________
>>From: Satish Thatte [mailto:]
>>Sent: Thu 7/15/2004 9:41 PM
>>To: Ashwini Surpur;
>>Subject: RE: [wsbpel-abstract] Potential requirements and use
>>case Aren't you confusing a use case with a set of
>>"requirements" marked with "MUST"?
>>
>>I am not opposed to the use of abstract BPEL for supporting
>>modeling tools, if it suits.
>>
>>I am opposed to structuring abstract BPEL in such a way that
>>it is ONLY or PRIMARILY focused on supporting modeling tools.
>>
>>There are several reasons for this.
>>
>>1. This is inconsistent with the current spec which expresses
>>the intentions of the original authors rather clearly, as well
>>as the charter. All of these emphasize the public view aspect
>>of abstract BPEL and it is not at all clear that the use of
>>OPAQUE is suitable for that.
>>
>>2. The *technical* motivation for this push away from the
>>original intentions is not clear -- it would be helpful to
>>have that explained.
>>
>>3. At a technical level, we recognize that abstract processes
>>are partially specified executable processes. One can provide
>>an external view as a partially specified process by
>>eliminating all unnecessary detail. One can also use the very
>>same partial specification as the basis for representing
>>intermediate states in a modeling exercise.
>>
>>In both cases you need a notion of faithful completion. I do
>>not buy that faithful completion is a purely syntactic matter
>>of specifying OPAQUE syntactic elements. This may be adequate
>>for some narrow use cases but is clearly suboptimal for the
>>technology as a whole.
>>
>>It is not, and has never been our charter to specifically
>>address the requirements of (visual or other) tools for
>>process modeling. I simply see no reason to bring that in as
>>the canonical use case.
>>
>>It is time we moved beyond this. Let us use the call tomorrow
>>to do so.
>>
>>Satish
>>
>>
>>
>>________________________________
>>
>>From: Ashwini Surpur [mailto:]
>>Sent: Thu 7/15/2004 4:49 PM
>>To:
>>Subject: [wsbpel-abstract] Potential requirements and use case
>>
>>
>>
>>Hi,
>>
>>Here is a use case and some requirements that we feel should
>>be satisfied. If needed, we can discuss this at tomorrow's conf call.
>>
>>Thanks,
>>Ashwini
>>
>>
>>
>>
>
>
