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)


Hi Monica,

Please see notes regarding your comments below.  Sorry not to have 
responded earlier... was busy getting 82 wrapped up after my trip and 
didn't look at updates on the other issues since I didn't expect things 
would go so well and we'd actually reach 107 in that call !

Here goes:


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

>> 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.
>
>
> [mm1 comment]
> Change from:
> One examples of using opaque activities includes creating process 
> templates (marking the points of normative extension in a process).
>
> Change to:
> One examples of using opaque activities could be the creation of a 
> process template that marks the points of extension in a process.
>
> [reason] Don't quite understand the use of template and extension in 
> the context you stated it.
>

[rk-re-comment 2] : Okay. Change accepted.

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

>> A.1 Opacity of activities allowed in the base:
>> Opaque activities are allowed.
>>
>> PART B - Opaque expressions:
>>
>> Opaque BPEL expressions shall be allowed exclusively for the use of 
>> abstract processes. An opaque
>> expression explicitly hides a corresponding executable BPEL expression.
>
>
> [mm1 comment] Did we not identify that the relationship may be other 
> than 1=1? How can we say then it is only one executable expression?
>

[rk-re-comment 3] I don't understand this question for expressions in 
particular. How can I have more than one expression as a while condition 
or as a case in a switch ? Do you have an example where we have multiple 
expressions in one place that could replace an opaque one. I can't think 
of any.

>> An example usage of an opaque expression is that of copying a hidden 
>> value into a known variable.
>> Opaque assignment can be used to express non-determinism: the obvious 
>> case being a process
>> that needs to show a decision point with alternative outcomes without 
>> specifying how the decision
>> is reached. In this case the expressions that constrain each branch 
>> may need to be left unspecified,
>> but it may also be convenient to make a specific value or quantity 
>> such as a price threshold
>> unspecified, so that explicitly specified conditions relative to the 
>> threshold become
>> non-deterministic as a result of the threshold value being unknown.
>
>
> [mm1 comment] Nothing here says that the outcome always raises to a 
> relevant state in the executable. Is there any need to specify that 
> there is some visible result for an opaque expression? Otherwise, 
> using your example, where is the decision point visible if at all?
>

[rk-re-comment 4] There isn't always a visible result for an opaque 
expression. I don't think this needs highlighting as it may be confusing.

>> All expressions in BPEL, and their corresponding opaque 
>> representations are
>> listed below:
>>
>> 1-Boolean valued expressions:
>>
>> -Transition Condition:
>> <transitionCondition expressionLanguage="anyURI"? opaque="yes"/>
>> -Join Condition:
>> <joinCondition expressionLanguage="anyURI"? opaque="yes"/>
>> -While Condition:
>> <condition expressionLanguage="anyURI"? opaque="yes"/>
>> -Switch Case Condition (editors’ note: reflect new if-then-else 
>> syntax) :
>> <case>
>> <condition expressionLanguage="anyURI"? opaque="yes"/>
>> activity
>> </case>
>>
>> 2- Deadline valued expressions:
>>
>> -Until element of onAlarm and wait:
>> <until expressionLanguage="anyURI"? opaque="yes"/>
>>
>>
>> 3- Duration valued expressions:
>>
>> -For element of onAlarm and wait:
>> <for expressionLanguage="anyURI"? opaque="yes"/>
>>
>> -repeatEvery element of onAlarm:
>> <repeatEvery expressionLanguage="anyURI"? opaque="yes"/>
>>
>> 4- Opaque From-Spec in Assignment:
>>
>> (Issue 103)
>>
>> <from expressionLanguage="anyURI"? opaque="yes"/> is allowed, and 
>> represents
>> hiding any of the forms of the 'from-spec'.
>>
>> -Opaque assignment (<from opaque="yes"/>) is used for capturing 
>> variable creation/modification
>> in a yet-to-be-concretized mechanism/fashion. See section 9.3.
>>
>> (editor’s note: update with any new expressions from any new activities)
>>
>> B.1 Opacity of expressions in the common base:
>>
>> All BPEL expressions are allowed to be opaque. The generic form of
>> opaque assignment is also allowed.
>>
>>
>> PART C - Opaque attributes:
>>
>> An opaque attribute hides the value of an executable BPEL attribute.
>>
>> For example, an opaque variable attribute in a receive activity hides
>> where the data is stored once the corresponding message is received.
>>
>> The reserved value “##BPELopaque” shall be made available for use as 
>> the value of any BPEL
>> attributes in a BPEL abstract process that can be opaque. (editor’s 
>> note: this may change to make
>> sure have a value for attribute types based on XSD.
>>
>> C.1: Opacity of attributes in the common base:
>> All BPEL attributes are allowed to be opaque in the common base.
>>
>>
>> ---------
>>
>> Rania's note on spec editing :
>> if 82 passes, then A.1, B.1, and C.1 could go in the bullets of the
>> common base where it says that it depends on 107.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 





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