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


David,
 
The TC is working on the BPEL 1.1 specification.  You can download [1]  a copy from the BPEL TC website.  
 
Which items do you consider to be showstoppers?   
 
While 100% interoperability is an admirable goal, I'm not sure how realistic it may be.  Nothing, to my knowledge, is ever 100% interoperable.
 
Re: Requirements Document, we will be discussing some formal processes for the TC in today's F2F/conference call.  I hope you can call into the meeting.  
 
JohnE
 
[1] http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/2046/BPEL%20V1-1%20May%205%202003%20Final.pdf

	-----Original Message----- 
	From: David RR Webber - XML ebusiness [mailto:Gnosis_@compuserve.com] 
	Sent: Wed 5/28/2003 4:19 PM 
	To: INTERNET:drj@us.ibm.com 
	Cc: wsbpel@lists.oasis-open.org 
	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.
	
	---------------------------------------------------------------------
	To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
	For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
	
	



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]