Re: [Fwd: Re: [wsbpel] Issue 82 - Adding requesting clarifications(withOUT change log)]

["Yaron Y. Goland" <ygoland@bea.com>]

 > How about :
 > "The semantics of an abstract process are therefore derived from the
 > range of executable BPEL processes that a particular abstract process
 > represents."

But this still requires the reader to draw the conclusion that an 
abstract process represents some kind of executable BPEL process. I 
think that is too strong a connection to draw. Especially since an 
abstract process may be specified that has no relation to any executable 
BPEL process that has or ever will exist.

	Yaron

Rania Khalaf wrote:
> Hi Yaron,
> 
> Yaron Y. Goland wrote:
>  > Then sentence "The semantics of an
>  > abstract process are therefore derived from those of the executable
>  > processes to which it would be mapped." confused me as it would imply
>  > that all abstract processes MUST be mapped to an executable process. But
>  > I was unaware of us ever wishing to imply that? Is the only possible use
>  > of an abstract process to create an executable process? I would draw a
>  > distinction with point 4 at the end of the proposal which just says that
>  > it must be possible to create an executable process through some fairly
>  > undefined mechanism. But that is different than implying that the end
>  > goal always is an executable process.
>  >
> 
> How about :
> "The semantics of an abstract process are therefore derived from the
> range of executable BPEL processes that a particular abstract process
> represents."
> 
> This removes the directionality while maintaining the concept.
> 
>  > "One or two profile(s) will be given in the specification. " - Which is it?
>  >
> 
> Whether it will be one or two profiles was intentionally left open as
> part of 82. We propose that a new issue be created to handle it.
> 
>  > "[The TC will rework the 1.1 AP definition into a profile with a
>  > defined URI." - This sentence seems incomplete
>  >
> 
> ?
> 
> 
>  > The proposal itself is still not in a form that is readily include-able
>  > in the spec.
> 
> see note at the end
> 
>  >The list of features of abstract processes is both
>  > incomplete (for example point 3 refers to opaque values without defining
>  > how they work, do you intend to resolve the dependent issue first?) and
>  > not in spec form.
>  >
> 
> The answer to this will come out of issue 107
> 
>  > I would expect that the final proposal would be in a form that is either
>  > ready to be included in the spec or reasonably close. That is the only
>  > way we can make sure that all the edge cases have been properly dealt
>  > with. Otherwise the editors will end up having to find those edge cases
>  > themselves and then file new issues. But it is not the job of the
>  > editing team to debug proposals.
>  > Nevertheless I am happy with the over all design and direction of the
>  > proposal. My comments are therefore restricted to encouraging that the
>  > proposal be completed so we can vote on it.
> 
> Looking into draft of spec to see where changes would occur, while
> making no assumptions about dependent specs other than putting
> place-holders.
> 
> Regards,
> Rania
> 
>  >
>  >     Thanks,
>  >
>  >         Yaron
>  >
>  >
>  > Rania Khalaf wrote:
>  >
>  >> Hi,
>  >>
>  >> here is the text with proposed updates incorporated and no
>  >> highlighting of changes.
>  >> -----------
>  >>
>  >> Proposal for Issue 82:
>  >>
>  >> NOTE: 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 from Peter
>  >> dated 12/15/2004.
>  >>
>  >>
>  >> Abstract BPEL definition:
>  >>
>  >>   A BPEL abstract process is a partially specified process that is not
>  >> intended to be executed. Executable and abstract BPEL processes share
>  >> the same expressive power, while the latter allows process definitions
>  >> that are capable of abstracting away operational details _ either
>  >> through omission or explicit opacity.  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'.
>  >>
>  >> Abstract processes serve a descriptive role, with more than one
>  >> possible purpose. One such purpose for an abstract process could be to
>  >> define the publicly visible behavior of some or all of the services it
>  >> offers ("myRole" in its partnerLinks), which may include its
>  >> interactions along its partnerLinks with other services.  Another
>  >> purpose could be to define a process "template" embodying
>  >> domain-specific best practices, encoded in a platform-neutral and
>  >> portable way by both enterprises and vertical standards organizations.
>  >> For example, a process "template" could capture some essential process
>  >> logic while leaving out operational details that will be concretized
>  >> when mapping the partial process specification to a fully executable
>  >> artifact.
>  >>
>  >> The different uses of abstract BPEL require different levels of
>  >> opacity and restrictions or relaxations on which elements of a
>  >> corresponding executable artifact are omitted or hidden.  To cleanly
>  >> enable different usages of abstract processes, an extensible approach
>  >> is taken using a set of basic, minimal requirements (base) for all
>  >> abstract processes.
>  >>
>  >> The abstract process base definition lacks well-defined
>  >> semantics. Conversely, executable processes have well-defined
>  >> semantics and prescribed behavior. From the abstract process base
>  >> definition, "usage profiles" can be defined. The semantics of an
>  >> abstract process are therefore derived from those of the executable
>  >> processes to which it would be mapped.
>  >>
>  >> To define these semantics, the range of corresponding executable
>  >> processes can be constrained by a usage profile, placing constraints
>  >> on what is opaque or omitted.  An abstract process MUST identify the
>  >> usage profile that defines its meaning.  The profile is identified
>  >> using a URI. Where profiles are defined is left unspecified.
>  >>
>  >> The base is simply a set of minimum requirements for all abstract
>  >> processes. Profiles are created from the base. One or two profile(s)
>  >> will be given in the specification. They/it will show how one can
>  >> create a profile by building on the base.
>  >>
>  >> [The TC will rework the 1.1 AP definition into a profile with a
>  >> defined URI.
>  >>
>  >> It is left open whether another profile will be defined in the
>  >> specification that is identical to the base. If so, it will be given a
>  >> URI to identify it and added. It is suggested that a separate, new
>  >> issue XX be opened for this. The dependency (by allowed closing order)
>  >> of these three issues is: 82, XX, 158.
>  >>
>  >> The placement of these profiles and other questions concerning the
>  >> structure of the ultimate specification and how many documents there
>  >> will be will be left open and dealt with as part of 158] . Issue 158
>  >> cannot be closed until 82 is closed.
>  >>
>  >>        Semantics of Abstract Processes:
>  >>
>  >>       [1] Although it might contain complete information that would
>  >> render it executable as specified for executable BPEL, its abstract
>  >> status states that any concrete realizations of it may perform
>  >> additional processing steps that are not relevant to the audience to
>  >> which it has been given. The minimum criteria for an abstract process
>  >> is defined in this specification while completeness is left to the
>  >> usage profile a particular abstract process definition belongs to.
>  >>
>  >>       [2] Abstract processes permit the use of all of the constructs of
>  >> executable processes. Thus there is no fundamental expressive power
>  >> distinction between abstract and executable processes.
>  >>
>  >>       [3] An abstract process may omit operational details that are
>  >> mandatory for BPEL executable processes through the use of "opaque"
>  >> entities of various types (i.e. elements, attributes, etc.) or through
>  >> the omission of specific BPEL elements or attributes that are allowed
>  >> to be implicitly opaque. This omission is treated as a syntactic
>  >> shortcut equivalent to the attribute or expression being in the
>  >> omitted location with an opaque value.
>  >>
>  >>       The semantics and consistency constraints of executable BPEL are
>  >> clearly defined. The semantics of each language construct in an
>  >> abstract process are always derived from that of the same construct in
>  >> executable BPEL. (i.e. an invoke is always an invoke).
>  >>
>  >>       The difference is strictly a consequence of the opacity used in
>  >> that construct (missing information) and other parts of the process
>  >> affected by it ( For example, opacity in a link source element may
>  >> affect the link target element).
>  >>
>  >>
>  >>       Additionally, an abstract process is required to be syntactically
>  >> valid using the BPEL schema, that accommodates extension with opacity
>  >> and omissions as detailed in bullet 3 above. One schema exists for
>  >> abstract and executable BPEL. (Check that this is consistent with
>  >> resolution of 24).
>  >>
>  >>       [4] In this base definition, to avoid absurd constructs and to
>  >> clarify opacity, the minimial 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.
>  >>
>  >>
>  >> This is used for checking the syntactic validity of an abstract
>  >> process not for process semantics.
>  >>
>  >>       [5] For this base definition, there are no requirements on how
>  >> concretized, executable realizations of abstract process should be
>  >> implemented (ie: language, platform, etc) (c.f. analogy to WSDL); nor
>  >> are specific relationships with such realizations specified.
>  >>
>  >>       [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* that are permitted by the profile
>  >> the abstract process references.
>  >>
>  >>       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.
>  >>
>  >>       __
>  >>
>  >>
>  >>
>  >>
>  >> To unsubscribe from this mailing list (and be removed from the roster
>  >> of the OASIS TC), go to
>  >> 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>  >>
>  >>
>  >
>  > To unsubscribe from this mailing list (and be removed from the roster of
>  > the OASIS TC), go to
>  > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>  >
> 
> 
>