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 - Proposal to Vote (pending 82)



>>> An opaque activity explicitly is a placeholder for exactly one 
>>> executable BPEL activity (not counting
>>> any activities that could be nested within that single executable 
>>> activity) whose behavior is not relevant
>>> to the recipient/user of the abstract process. An opaque activity is 
>>> a BPEL activity and therefore has
>>> the same standard elements and attributes that all BPEL activities 
>>> have (see spec section 11.1 and
>>> 11.2). It has the following form:
>>>
>>> <opaqueActivity standard-attributes>
>>> standard-elements
>>> </opaqueActivity>
>>
>> [mm1 comment] Choice may be not to expose this behavior - whether it 
>> is relevant or not may be a meta-semantic
>> question, which we have chosen not to address. This brings into 
>> question if opaque=executable BPEL activity always.
>
> [rk-re-comment 1]   In light of the discussion on the call regarding 
> this topic (whether opaque=exec BPEL activity always) brought up by 
> Yaron, and the conclusion reached there that this would be the case 
> for a number of reasons (mainly links, suppressjoin, etc ..), I expect 
> that this point has been resolved. 

mm2: Perhaps then we recognize and make a simple statement that 
semantics may exist outside of BPEL that could define the purpose, the 
choices or exposing of behavior (other than the syntactic guidelines or 
operational semantics we provide in the scope of WS-BPEL).  This relates 
to other question below.

>>> One examples of using opaque activities includes creating process
>>> templates (marking the points of normative extension in a
>>> process). Another is when creating an abstract process from a known
>>> executable process and wanting to hide an activity that is a join
>>> point for several links. If that activity, on the other hand, had just
>>> been an unlinked activity in a 'sequence' it could have just been 
>>> omitted
>>> from the resulting abstract process.
>>
> At first glance, it seems that this could instead be done using 
> <empty>. The difference is that <empty> explicitly says "nothing 
> happens here," whereas <opaqueActivity> is really saying "something 
> happens here, but it's hidden on purpose".
>
>> [mm1 comment] The hidden purpose may result in no activity so this 
>> could be somewhat contradictory (or misconstrued).
>>
>> Change from:
>> The difference is that <empty> explicitly says "nothing happens 
>> here," whereas <opaqueActivity> is really saying "something happens 
>> here, but it's hidden on purpose".
>>
>> Change to:
>> The difference is that <empty> explicitly says "nothing happens 
>> here," whereas <opaqueActivity> is really saying "something happens 
>> here, but the choice is to hide it".
>
> [rk-re-comment 3]: I don't understand the difference between 'hidden 
> on purpose' and 'the choice is to hide it' ?  the latter seems to be 
> the same asa 'hidden by choice' which is kinda the same as 'hidden on 
> purpose' ... then again I'm not a native speaker so clarification welcome.




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