Hi,
Yes, Mark's example should be allowed.
Yes, agree with Danny that adding two examples that we have just
created would benefits users a lot.
And, few minutes ago, I sent out some suggested text, which treats link
as a part of standard-elements and dangling link case as one of
examples of static analysis.
IMHO, having a general statement on what to ignore and what not to
ignore is a better option than singling out links for special treatment.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
I'm thinking that
<extensionActivity>
<other:notUnderstoodExtendedSequence>
is one activity, while you're thinking they're two.
All links will cross the <extensionActivity> element boundary
to a contained element. However, your example doesn't
cross the <extensionActivity> activity boundary,
while mine does. At least if one interprets the above 2 elements as
one activity.
It seems to me that all the careful wording in the world, though, even
if it's 1000 words' worth, won't equal the examples we've just created.
Mark Ford wrote:
Should
this be allowed:
<flow>
<link name="crossesExtensionActivity"/>
<receive>
<source name="crossesExtensionActivity"/>
</receive>
<extensionActivity>
<other:notUnderstoodExtendedSequence>
<target name="crossesExtensionActivity"/>
<invoke/>
<validate/>
<assign/>
</other:notUnderstoodExtendedSequence>
</extensionActivity>
</flow>
The above example collapses
easily enough into an empty without any errors.
The <extensionActivity>
element doesn't have the standard attributes and standard elements so
we should be careful about boundary crossing terminology since all
links will cross the <extensionActivity> boundary into a
contained element.
How does this sound:
Links MUST NOT cross an
extensionActivity into an activity that is not the immediate child of
the <extensionActivity> unless the namespace for the extension
has been declared with a mustUnderstand="yes".
Alex -
If the original wording caused you to understand it that way, then it
does need to be changed. However, your rewording doesn't match the
intent of what Rania and I were working towards.
- 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.
We weren't suggesting a normative change here. We were pointing out
resultant behavior.
We weren't saying to ignore the links in an extensionActivity. We were
saying that if there's something like:
(syntax compressed for ease of my typing...)
<flow>
<link name="crossesExtensionActivity"/>
<receive>
<source name="crossesExtensionActivity"/>
</receive>
<extensionActivity>
<other:notUnderstoodExtendedSequence>
<invoke/>
<validate/>
<assign>
<target name="crossesExtensionActivity"/>
</assign>
</other:notUnderstoodExtendedSequence>
</extensionActivity>
</flow>
then the fact that someone won't understand the
notUnderstoodExtendedSequence means that they're not going to know what
to do with the assign embedded inside. Since that assign contains the
target of the link, they won't know what to do with the process.
Therefore to maintain portability, we're proposing that ALL processors
must reject the process. Note that we're not talking about standard
elements on the extensionActivity itself, but those contained within
embedded activities.
First - do you agree with that sentiment?
Second - if you do, then we can go ahead with new wording, possibly
with an example.
I think the simplest wording, that doesn't include any rationale or
examples, etc., would be along the lines of:
Any link that has an extensionActivity as a source or target is legal.
However, links MUST NOT cross an extensionActivity into a contained
activity if the namespace of the extensionActivity is not declared
with mustUnderstand="yes."
Granted that still isn't simple...
Alex Yiu wrote:
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
|