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 92 - 92.3 - Allow BPEL specified elements and attributesto be extended - Proposal For Vote

This is a very subtle matter, I agree; however, the principle that when you
find a BPEL element you can safely assume the semantics that the spec
assigns to it is a sound one. In addition to those semantics (but not
instead of them) you'll need to consider whatever the extensibility
elements included are also included. The key point is that an extension may
"extend" the existing semantics, not replace them. Otherwise you should not
be writing BPEL.

I would be ok mentioning this extension principle explicitly, but I am not
comfortable with the proposal below because it seems to open the door for
arbitrary 'mutations' of BPEL construct semantics.


                      "Yaron Y. Goland"                                                                                           
                      <ygoland@bea.com>        To:       wsbpeltc <wsbpel@lists.oasis-open.org>                                   
                      02/28/2005 09:46         Subject:  [wsbpel] Issue 92 - 92.3 - Allow BPEL specified elements and attributes  
                      PM                        to be extended - Proposal For Vote                                                
                      Please respond to                                                                                           

Section 6.3 of the specification current states that extensions must not
change the semantics of attributes and elements in BPEL. This rather
defeats the point of allowing extensions, especially of the mandatory
variety, whose purpose in life is often to change the semantics of
things in BPEL. In practice the current restriction isn't enforceable
since there really is nothing to stop someone from introducing an
extension that changes existing BPEL semantics. But as a general rule I
think it's good to avoid unenforceable rules and instead provide
actionable guidance. With that in mind I propose:

Section 6.3

From: Extensions MUST NOT change the semantics of any element or
attribute from the WS-BPEL namespace.

To: Extensions that change the semantics of elements or attributes in
the WS-BPEL namespace MUST either be backwards compatible with the
definitions provided in this specification or MUST be declared as a
mandatory extension. See section 13.7 for information about mandatory



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]