Hi Danny and Rania,
[a]
I generally agree with sentiment (which have not been clearly defined
yet), as expressed in the last conf call.
[b]
The original wording was not precise enough. The word "enclosed" covers
a lot of situation that you guys may not intend to. Let me try to
clarify the intended semantics based on your example and a modified
version of example.
Example #1 (your original example):
------------------------------------------------------
<flow>
<link name="crossesExtensionActivity"/>
<receive>
<source name="crossesExtensionActivity"/>
</receive>
<extensionActivity>
<other:notUnderstoodExtendedSequence>
<invoke/>
<validate/>
<assign>
<target name="crossesExtensionActivity"/>
</assign>
</other:notUnderstoodExtendedSequence>
</extensionActivity>
</flow>
------------------------------------------------------
If "notUnderstoodExtendedSequence" is not understood, this process
definition should be rejected because of dangling links.
Now, let me slightly modify the example:
Example #2:
------------------------------------------------------
<flow>
<link name="crossesExtensionActivity"/>
<receive>
<source name="crossesExtensionActivity"/>
</receive>
<extensionActivity>
<other:notUnderstoodExtendedSequence>
<target
name="crossesExtensionActivity"/>
<invoke/>
<validate/>
<assign>
</assign>
</other:notUnderstoodExtendedSequence>
</extensionActivity>
</flow>
------------------------------------------------------
If "notUnderstoodExtendedSequence" is not understood, this process
definition will still be accepted. Because, the current spec text says:
"In all cases however any standard-attributes or
standard-elements used on the contained activity MUST be treated as
defined by this specification."
And, its execution is treated as if the following:
------------------------------------------------------
<flow>
<link name="crossesExtensionActivity"/>
<receive>
<source name="crossesExtensionActivity"/>
</receive>
<empty>
<target name="crossesExtensionActivity"/>
</empty>
</flow>
------------------------------------------------------
[c]
If interpretation of the above these examples fits your intention, I
would suggest the following new wordings:
--------------------------------------
In such a case (where the <extensionActivity> is treated as
<empty>)
all enclosed constructs, excluding standard attributes and elements,
in the <extensionActivity> MUST be
ignored by a processor that does not understand the
extension. Examples of ignored constructs
are:
- a WS-BPEL standard activity embedded
within the <extensionActivity>
- a WS-BPEL link source or target
construct embedded not as a standard element directly associated with
the <extensionActivity>.
Further static analysis is performed after
applying ignoring semantic. For example, if a link target is buried
more than one level deep inside an <extensionActivity> and the
link crosses the boundary of the <extensionActivity>, such a
process definition is rejected by a
WS-BPEL
processor, which does not understand
the <extensionActivity>, as a
dangling link is resulted.
--------------------------------------
And, the following statement of current spec text stays:
"In all cases however any standard-attributes or standard-elements used
on the contained activity MUST be treated as defined by this
specification."
Note that: report and discovery of dangling link after applying
ignoring semantic is just one of cases of static analysis. Say, in
future, if we define a static analysis rule that says, if <reply>
of a request-response op is completely missing in a process definition,
where an open IMA exists, the above ignoring semantic can still be
applied elegantly.
I hope the new wordings fit expectation of you guys.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
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
|