[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 82 - Proposed resolution for vote (revised)
> 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  , 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. ** Add: The base is a set of minimum requirements for all abstract processes. ** 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.  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.  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.