[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 92.6 - proposal draft
See inline. Thanks, Alex. > Yiu: 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"? mm2: The comment was more so prefaced, Alex, on if the additional SHOULDs 'should' be included. I understand there may be other requirements you may have in mind to satisfy here. Are they technical considerations? Ron and I suggest we gain more experience before adding more details. > 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. mm2: This may evidence that we need more experience before specifying additional MUST or SHOULD. See comments above. > Thanks! mm2: You are welcome. >> mm1: 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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]