Re: [wsbpel] Issue - 92.6 - proposal draft

[Alex Yiu <alex.yiu@oracle.com>]

Monica,

Thanks for your feedback. I have a relatively open mind here.
There are two parts of my proposal. The first part is a MUST 
requirement. The second part is a SHOULD recommendation.

Do you have a use case whether bounding the semantics to its syntactic 
scope is too restrictive? Is there any particular parts of my "MUST" 
wording should be turned into "SHOULD"?

Another point which may be helpful for clarification:
----------------------------
<scope>
    ...
    <partnerLink name="pl1" foo:bar="..." ... />
    <partnerLink name="pl2" ...  />
    ...
    <invoke partnerLink="pl1" ... />
    <invoke partnerLink="pl2" ... />
    ...
</scope>
----------------------------

The restriction is to mean the "foo:bar" extension is applicable to 
"pl1" only, not "pl2".
And, of course the extension effect of "foo:bar" will be carried along 
with partnerLink "pl1", including the the usage in the <invoke> activity.

If the above example explain the MUST restriction better, I could change 
that.


Actually, the wording of "cannot modify" is a bit too restrictive, 
except for tool-based extension (e.g. IDE BPEL diagram layout). Most of 
BPEL runtime extensions do apply twists to existing BPEL standard 
semantics. For example, if engine-managed message correlation exists as 
a form of extension to partnerLink or message-related activities.

There is another 92.3 subissue to track that down.

Thanks!



Regards,
Alex Yiu


Monica J Martin wrote:

> From Ron Ten-Hove and I:
>
> Alex, I understand you working hard to bound extensible elements, but 
> the SHOULD guidelines at the end really are implementer hints. Are 
> these necessary? Should we consider bounding the semantics of an 
> extension to its syntactic scope? We already safeguard the semantics 
> of BPEL, stating that extensions cannot modify them. Thank you.
>
>> Yiu: Hi all,
>> Here is the proposal draft (as promised in the last conf call) for 
>> Issue 92.6.
>> If not controversial, I shall move it as the formal proposal soon.
>>
>> ------------------------------------------------------------------------
>>
>>
>>       Proposal Draft for Issue 92.6: need for an explicit syntax token
>>       to apply extension semantics from a NS URI
>>
>> Last modified: May 01, 2005 - 6 pm PDT
>>
>> Applied the following the text to the paragraph describing 
>> <extension> syntax:
>>
>> --------------------------------------------
>> An extension declaration through <extension> syntax does not 
>> automatically imply the application of any extension semantics 
>> defined in the corresponding namespace to the process definition. It 
>> merely declares the properties of the namespace of extension, such 
>> as, using "mustUnderstand" attribute to denote whether a WS-BPEL 
>> processor can safely ignore related extensions.
>>
>> In order to apply an extension semantics to a WS-BPEL process 
>> definition, one MUST use and include the corresponding syntax token 
>> (either in an element form or an attribute form) explicitly in the 
>> WS-BPEL source code and attach the token to a WS-BPEL extensible 
>> construct.
>>
>> The extension semantics can ONLY affect BPEL constructs within the 
>> syntax sub-tree of the element where the explicit syntax token 
>> attached to. In other words, extension syntax token MUST NOT "leak" 
>> its semantics outside the subtree. As WS-BPEL source code itself is 
>> an XML document, the definition of syntax sub-tree is trivial and can 
>> be borrowed from self-or-descendant concept from XML world. Here are 
>> two examples to illustrate the above concept further:
>>
>> <process>
>>     ...
>>     <scope>
>>         <sequence>
>>            <invoke operation="operation1"
>>                      foo:invokeProperty="someNature" ... />
>>            <invoke operation="operation2" ... />
>>            <invoke operation="operation3"
>>                      foo:invokeProperty="someNature2" ... />         
>> </sequence>
>>     </scope>
>> </process>
>>
>> The "foo:invokeProperty" extension attribute are applied to <invoke> 
>> activities for "operation1" and "operation3". The <invoke> activity 
>> for "operation2" MUST NOT be affected.
>>
>>
>> <process>
>>     ...
>>     <scope>
>>         <foo:invokeProperty>someNature</foo:invokeProperty>
>>         <sequence>
>>            <invoke operation="operation1" ... />
>>            <invoke operation="operation2" ... />
>>            <invoke operation="operation3" ... />         </sequence>
>>     </scope>
>> </process>
>>
>> On the other hand, the "foo:invokeProperty" extension element can be 
>> potentially applied to all <invoke> activities within the <scope> 
>> activity where the extension element are attached to.
>>
>> Apart from the above "MUST" restrictions, here are some extra 
>> "SHOULD" guidelines for the design of extension syntax and semantics:
>>
>>     * Each extension syntax token SHOULD carry only semantics that
>>       fits into a relatively modular and elegant boundary. An counter
>>       example of bad design would be: one single extension syntax that
>>       carries dozens of overloaded extension semantics ranging from
>>       transaction to security, from message delivery QoS to XML data
>>       manipulation shortcuts. One should break down the above variety
>>       of extension semantics into different extension syntax token.
>>     * Each extension syntax token SHOULD have a set of well-defined
>>       attachment points, instead of making an extension syntax
>>       applicable to every BPEL extensible constructs. Using the
>>       "invokeProperty" example above, the set of attachment points are
>>       <invoke> and <scope> constructs. Designers of extension are
>>       encouraged to keep the set of attachment points small within
>>       reasons and to try to avoid using grander level constructs (e.g.
>>       <process> and <scope>) as attachment points  unless the
>>       semantics of extension require.
>>
>>
>> --------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> 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  
>>
>
>
>
> ---------------------------------------------------------------------
> 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