Re: [wsbpel] Issue 92 - 92.3 - Allow BPEL specified elements andattributes to be extended - Proposal For Vote

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

As you point out, there is absolutely nothing we can do to stop people 
from making non-backwards compatible changes to BPEL's semantics. So 
putting in a requirement that people not do that is futile.

What we can do however is give people guidance on how to do good 
extensions. Which is what this text does. It states - if your change 
isn't backwards compatible then mark it as mandatory and if it is, then 
you can use optional.

It certain must be better to provide people with concrete productive 
advice than make blanket statements (as the spec currently does) that 
are inherently unenforceable?

		Yaron

Assaf Arkin wrote:
> -1
> 
> 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.
> 
> Assaf
> 
> 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
>>
>>
>