RE: Issue - 2- Why I think we should close Issue 2

["Eckenfels. Bernd" <B.Eckenfels@seeburger.de>]

Ivana,

from the charter:

> At the TC's option, suggestions for future features, out-of-scope
> extensions, harmonization with other or broader work and the like
> may be noted and archived for possible future work after the
> conclusion of this TC's lifecycle.

So keeping a list with TODOs may not be wrong. However I agree that in the specific case it is better to defer the resolution upon more results rom the use case group.

Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de


-----Original Message-----
From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com]
Sent: Wednesday, November 26, 2003 9:56 AM
To: 'ygoland@bea.com'
Cc: Eckenfels. Bernd; wsbpel@lists.oasis-open.org
Subject: RE: Issue - 2- Why I think we should close Issue 2


Yaron,

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,

Ivana

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