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 - 107 - Extension points and opacity


It all depends on what you mean by empty. Does empty mean 'I'm not 
saying' or 'I won't do anything'? Given the ambiguity I don't think it's 
appropriate to speak of opaque as an alias for empty. If anything opaque 
is a superset of empty.

Opaque is a very straight forward statement - I am not telling you what 
happens in this part of the code.

This means that an opaque could be replaced with any possible code 
including but certainly not limited to 'empty'.

		Yaron

Assaf Arkin wrote:

> 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
>>>
> 


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