Re: [wsbpel] Issue - 107 - Extension points and opacity

[Assaf Arkin <arkin@intalio.com>]

Sorry. The examples you provided in your e-mail seems to suggest the 
/opaque /activity has some semantic meaning. The statement below seems 
to suggest it's equivalent to /empty/, and that it should be treated as 
such when reading a BPEL abstract definition, its absence or presence 
being nothing more than syntactic sugar. My fear here is that people 
will interpret its meaning as different than an alias for /empty/.

Assaf


Yaron Y. Goland wrote:

> No, it would not. Please see the other mails on this thread as this 
> specific topic got a lot of discussion.
>     Thanks,
>         Yaron
>
> Assaf Arkin wrote:
>
>> Will the specification of an abstract process state that all 
>> implementations are only allowed to add behavior where /opaque/ 
>> exists in the abstract and are otherwise obliged to contain the same 
>> activity flows as defined in the abstract?
>>
>> Such a statement would clearly point out the difference between 
>> /opaque/ and /empty//nothing.
>>
>> But then I would like to also have a specific definition of what that 
>> added behavior consists of. If implementation details that are not 
>> observable to my partner (not their business) have to be masked by 
>> /opaque/, then all of a sudden everything I do that is not observable 
>> by/of concern to my partner has to be opaqued, which means /opaque 
>> /before and after each activity.
>>
>> Is there any precise definition of what needs to be opaqued so that 
>> we can decide whether or not an implementation is consistent with the 
>> abstract?
>>
>> Assaf
>>

S/MIME Cryptographic Signature