[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 250 - Proposal for Vote
Hi DK, I am with you there. I don't think droping links attached the unrecognized extension activity is a good idea either. And, that is a normative change. It's just the "enclosed" wording in original proposal text is a bit too vague and board that lead users (including me) to read into the cases, that the orginal proposal did not intend to disallow. And, ignoring sementics applied to "deeply embedded" links should be applied to any "deeply embedded" BPEL standard construct as well (e.g. <reply> activity). I sent out an email on Friday 3pm (PST). That contains some text to attempt to clarify the intention of this proposal. Danny seems to like the direction. But, he may want to refine the wordings. Let's refine those wordings more ... Thanks! Regards, Alex Yiu Dieter Koenig1 wrote: >-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 > > > > >--------------------------------------------------------------------- >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]