[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Groups - BPEL4WS 1.1 Issues Log May 23.doc uploaded
Diane, Some questions: <Excerpt> Purpose of Document This document is intended to describe and track those items that the technical committee believes need to be analyzed and resolved for the next version of the BPEL4WS specification. </Excerpt> >>>> Does this mean "this" version - ie. BPEL V1.0, or BPEL Vx.xx ??? Since some of these items are clearly 'show stoppers' - I hope this means V1.0 <<< <Excerpt> 1. Non-mutability of correlation sets Clarification: the value of a correlation set once initialized is immutable, but this does not apply to the individual properties in the set, which may be shared with other sets. Thus the set should be thought of as a late-bound constant as a whole. The properties are just means of defining it. Questions: How much checking can be done at definition time and how much at execution time? Do we need a runtime fault? </Excerpt> >>> I think we need to understand the operational requirements here - and THEN figure out the mechanism to provide those. These folks seem to have built something - then coming back and are asking if that is what was needed? <<< <Excerpt> 2. Static analysis Static analysis is a well-established technique to support robust design and implementation practice. The specification permits that static analysis may reject a BPEL process definition, depending on how pessimistic the static analysis is. As a result, some BPEL definitions may not be portable between different BPEL implementations. Question: Is it possible to define a conservative set of restrictions that will ensure portability? </Excerpt> >>> The bigger question again is first of all - what level of interoperability is required for BPEL - and how fundamentally is this going to be achieved? If the answer is 100% - then any features that do not provide that - need to be tossed out. If the answer is less than 100% - then non-interoperable features need to be classified and a section of the spec' dedicated to describing mechanisms that can only be used internally / and / or are optional for conforming BPEL processors. <<< Do we have a plan yet for producing a formal Requirements document? Thanks, DW.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]