OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]