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: Issue - 2- Why I think we should close Issue 2


I may agree that it will take some time to resolve this issue (mostly because the group disagrees how to approach it, but this is a common situation when a work is done in such a big group). I do not believe that the issue is technically challenging. There is an agreement to try to resolve issues relating to coordination between processes first. If we do not succeed we will come back and reconsider other approach, which should be in line with your proposal (I appreciate your contribution to that discussion). 

Therefore I do not support your suggestion to prematurely close this issue. Also, collecting requirements for next version(s) of the upcoming standard is not task of this group.

Kind regards,


> -----Original Message-----
> From: Yaron Goland [mailto:ygoland@bea.com]
> Sent: Dienstag, 25. November 2003 22:17
> To: Trickovic, Ivana; 'Eckenfels. Bernd'
> Cc: wsbpel@lists.oasis-open.org
> Subject: Issue - 2- Why I think we should close Issue 2
> Over the last two months I have made a series of proposals for how to
> introduce sub-functions to BPEL:
>  * http://lists.oasis-open.org/archives/wsbpel/200310/msg00355.html
>  * http://lists.oasis-open.org/archives/wsbpel/200310/msg00366.html
>  * http://lists.oasis-open.org/archives/wsbpel/200310/msg00367.html
>  * http://lists.oasis-open.org/archives/wsbpel/200310/msg00368.html
>  * http://lists.oasis-open.org/archives/wsbpel/200311/msg00021.html
>  * http://lists.oasis-open.org/archives/wsbpel/200311/msg00023.html
> Having spent this time living with these proposals I have come to the
> conclusion that it will take us a significant amount of time to get
> everything right and ready for implementers to implement.
> My personal belief is that customers will benefit more by 
> getting the BPEL
> spec out as early as possible than by having sub-functions in 
> the first
> version of BPEL. Sub-functions are something that we can 
> safely add in later
> as an extension and I would certainly expect them to be part 
> of the next
> version of BPEL.
> Therefore I propose that we close Issue 2 with a note that 
> the matter should
> be considered by those working on future versions of BPEL.
> 		Yaron

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