[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 82 - Adding requesting clarifications (with changelog)
Hi everyone, Monica, Ron, Peter, and I took a stab at incorporating Monica and Ron's requested clarifications with my response and Peter's text on 82. We tried very hard to ensure that changes clarify/make consistent the text below *without changing the content and intent*. This text is provided for consideration, as input towards addressing the TC's request that requested clarifications be handled before 82 can be closed. I will also send a version without the change log that should be easier to read from start to finish. Best Regards, Rania (w/ Monica, Ron, and Peter). ------ key: red = changes. (Additions, unless otherwise specified.) **addressing (x)** precedes each, where (x) is the item number from Monica and Ron's email of concerns. --------------------------------------------- **addressing (4)** IMPORTANT NOTE ON 82: -------------------------------- 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. may **addressing (a)** deleted: "or when mapping it to "
**addressing (b,c)** Replace: A BPEL abstract process can Wiith: One such purpose for an abstract process could be **addressing (b,c)** Replace: Alternatively, a BPEL abstract process With: Another purpose could be to **addressing (b,c)** Replace: 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. With: 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. **addressing (d)** Replace: 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 behaviour of the executable process as a whole, and is thus not directly available outside an executable process. With: 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. **addressing (e)** Replace: process it could be mapped to. With: processes to which it would be mapped. **clarification** Replace: with a URI. With: The profile is identified using a URI. **addressing (e)** Replace: Profiles may be defined by anyone - in separate standardization efforts, internally in organizations or for proprietary usage, etc. With: 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. **addressing: (1,2,3,f) ** REPLACE: [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] ) WITH: 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. **addressing (e, 3)** Issue 158 cannot be closed until 82 is closed. **addressing (g) ** language **addressing (g) ** are always **addressing (g) ** (i.e. an invoke is always an invoke). **addressing (h)** Replace: Addionally, an abstract process is required to be syntactically valid using the executable schema extended with the opaque entities. With: 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). **addressing (j)** This is used for checking the syntactic validity of an abstract process not for process semantics. **addressing (k)** Replace: it permits With: that are permitted by the profile the abstract process references.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]