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 andattributes to be extended - Proposal For Vote


There's nothing to step someone from introducing and supporting an 
extension that changes BPEL semantics, not from just deciding to 
interpret BPEL elements differently from the spec. But we do want to 
know what a complaint/conformant/insert-your-word-here implementation 
would do, and as long as it's used in this manner, it shouldn't deviate 
from the spec.

In other words, when the BPEL implementation honors the spec, it can 
accept an extension that rings a bell every time a sequence starts 
executing (no change to semantic), but reject an extension that reverses 
the order of activity executing in the sequence (change to semantic). 
Any rules on how to not honor the spec, I assume, would be outside the 
scope of the spec.


Yaron Y. Goland wrote:

> 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 
> extensions.
>        Thanks,
>                 Yaron
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org

fn:Assaf Arkin
adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065
title:Chief Architect
tel;work:(650) 596-1800

S/MIME Cryptographic Signature

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