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] Issue - 158 - Changing Spec Structure from 3 part to 2 part






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
.





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