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 250 - Proposal for Vote


Title: [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]