Re: [wsbpel] Issue - 158 - Changing Spec Structure from 3 part to2 part

["Yaron Y. Goland" <ygoland@bea.com>]

I suspect we will have to wait for the outcome of the abstract process 
sub-group before we will be ready to settle this issue one way or another.

Francisco Curbera wrote:

> 
> 
> 
> 
> There are legitimate concerns about readability, in particular about having
> related material spread across many sections of the specification.They need
> to be addressed, but not at the expense of the core+extensions structure of
> the specification.
> 
> The structure of the specification (base + extensions) was intentionally
> designed to provide common semantics for the executable and abstract use
> cases, while supporting differentiation to address each scenario properly.
> It is also required to enable BPEL to adapt to other scenarios where BP
> languages are used, maintaining the same core language primitives. As such
> I think the core+extensions strategy is an absolute necessity to realize
> the full benefits of a standard, industry wide BP language.
> 
> The proposed solution to this issue makes executable the base and defines
> deltas (things to add or remove from the executable language) for the
> abstract use case. This approach has the problem of not identifying clearly
> what is the common core of concepts that all flavors of BPEL would share.
> In fact the common base would be implicitly redefined every time a new
> extension is introduced; chances are that the common subset would end up
> being meaningless. This is one important reason why the spec needs to
> clearly identify the core semantics that all BPEL users must share.
> 
> Paco
> 
> 
> 
> 
> 
>                                                                                                                                           
> 
> 
>                       ws-bpel issues 
> list                                                                                                 
> 
> 
>                       editor                     To:       
> wsbpel@lists.oasis-open.org                                                    
> 
> 
>                       <peter.furniss@chor        
> cc:                                                                                      
> 
> 
>                       eology.com>                Subject:  [wsbpel] 
> Issue - 158 - Changing Spec Structure from 3 part to 2 part          
> 
>                                                                                                                                           
> 
> 
>                       08/04/2004 07:55 
> PM                                                                                                 
> 
> 
>                       Please respond 
> to                                                                                                   
> 
> 
>                       
> wsbpel                                                                                                              
> 
> 
>                                                                                                                                           
> 
> 
> 
> 
> 
> This issue has been added to the wsbpel issue list. The issues list is
> posted as a Technical Committee document to the OASIS WSBPEL TC pages on a
> regular basis. The current edition, as a TC document, is the most recent
> version of the document entitled in the "Issues" folder of the WSBPEL TC
> document list - the next posting as a TC document will include this issue.
> The list editor's working copy, which will normally include an issue when
> it is announced, is available at this constant URL.
> Issue - 158 - Changing Spec Structure from 3 part to 2 part
> 
> 
> Status: open
> Categories: specification editing
> Date added: 4 Aug 2004
> Submitter: Yaron Y. Goland
> Date submitted: 04 August 2004
> Description: The specification currently has three main sections, a 'base'
> section, an 'executable' section and an 'abstract' section. This means that
> issues like variable handling and schema validation requirements get spread
> across multiple sections which makes the spec both hard to read and hard to
> use as a reference when implementing.
> Submitter's proposal: We should restructure the specification into two
> parts. A first part would deal exclusively with executable BPEL and would
> define how executable BPEL works in a consistent manner. The second part
> would then define abstract BPEL, mostly in terms of how it is different
> than executable BPEL.
> Changes: 4 Aug 2004 - new issue
> 
> 
> 
> To comment on this issue, please follow-up to this announcement on the
> wsbpel@lists.oasis-open.org list (replying to this message should
> automatically send your message to that list), or ensure the subject line
> as you send it starts "Issue - 158 - [anything]" or is a reply to such a
> message. If you want to formally propose a resolution, please start the
> subject line "Issue - 158 - Proposed resolution", without any Re: or
> similar.
> 
> 
> To add a new issue, see the issues procedures document (but the address for
> new issue submission is the sender of this announcement).
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php 
> 
> .
> 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of 
> the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. 
> 
>