[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 250 - Proposal for Vote
-1 (I am NOT in favor of ignoring/removing links crossing the boundary of an extension activity). Consider a situation where there is a link from A1 to A2 and one from A2 to A3, and A2 is contained in an extension activity while A1 and A3 are not: A1 source linkName="link1" extensionActivity unknownActivity A2 target linkName="link1" source linkName="link2" A3 target linkName="link2" Dropping the links would result in loosing the control dependency between activities A1 and A3 which IMO is not acceptable. Kind Regards DK Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220 Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany Alex Yiu <alex.yiu@oracle. com> To Danny van der Rijn 31.03.2006 22:48 <dannyv@tibco.com> cc Rania Khalaf <rkhalaf@watson.ibm.com>, wsbpeltc <wsbpel@lists.oasis-open.org>, "Yiu,Kwok Lun" <ALEX.YIU@oracle.com> Subject Re: [wsbpel] Issue 250 - Proposal for Vote Hi, Rania and others, I would also suggest removing the implementer's note. Few more points to suggest/make: If we decide to make a normative change to ignore links within an extensionActivity that a WS-BPEL Processor does not understand. We should apply this ignore semantic consistently to all standard attributes and elements. I am not sure the "if-then" logic about a link crosses the boundary of an <extensionActivity> is crispy clear. People may mis-read it in a way that "mustUnderstand" declaration can be set/reset by a WS-BPEL processor itself. It also implies a potential confusing error message "Cannot understand an extension declared with mustUnderstand='yes' ..." instead of "Dangling links ..." The term "artifact" usually refers to something with a bigger granularity. I would suggest to use "construct" instead. That is also more consistent with other parts of the spec. -------------------------------------- In such a case (where the <extensionActivity> is treated as <empty>) all enclosed constructs, including standard attributes and elements, in the <extensionActivity> MUST be ignored to a processor that does not understand the extension. Ignoring standard elements would imply ignoring links in some cases. If a link crosses the boundary of an <extensionActivity>, which a processor does not understand, dangling links are resulted and such a process definition is rejected. -------------------------------------- Also, remove the sentence started with "In all cases however any standard-attributes or standard-elements ..." Regards, Alex Yiu Danny van der Rijn wrote: I would remove the implementer's note. Danny Rania Khalaf wrote: CURRENT TEXT ON EXTENSION ACTIVITY IN SECTION 10: If the element contained within the extensionActivity element is not recognized by the BPEL processor and is not subject to a mustUnderstand="yes" requirement from an extension declaration then the unknown activity MUST be treated as if it were an empty activity. In all cases however any standard-attributes or standard-elements used on the contained activity MUST be treated as defined by this specification. INSERT AS BEFORE TO LAST SENTENCE (between 'empty activty' and 'in all cases'): In such a case (where the <extensionActivity> is treated as <empty>) all enclosed artifacts, including links, in the <extensionActivity> are not visible to a processor that does not understand the extension. To avoid dangling links in these situations, the following restriction must be met. If a link crosses the boundary of an <extensionActivity>, then the element contained within the <extensionActivity> MUST be subject to mustUnderstand="yes". Implementers note: This can be detected if a processor that does not understand certain extensionActivities replaces them with <empty> activities *before* doing static validation. --------------------------------------------------------------------- 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]