The problem that I have with Option #1 AND Option #2 is that if someone
doesn't understand the bar namespace, then they lose the ability to
preserve link structure in a flow. That seems to be pretty broken.
Alex Yiu wrote:
Hi all,
Some of you guys may wonder how [option #1] is related to sub issue
111.1. Basically, if the web ballot result picks [option #1], that
means we will effectively pick the original proposal attached to the
issue description (instead of the alternative one) to continue the rest
of Issue 111. [See:
http://lists.oasis-open.org/archives/wsbpel/200503/msg00040.html
].
Two and half months have passed. I believe there are some new factors
that we need to consider regarding to the extension syntax design issue
as we progress in Issue 111 (which is not a common situation, generally
speaking) Here is more background on why it worths our efforts to
evaluate all feasible options with an open mind.
[Side Note: Please also keep in mind we did change some BPEL 1.1 design
in BPEL 2.0. E.g. changing a termination fault handler to
terminationHandler. and, we add <sources> and <targets>
wrapper as well in BPEL 2.0]
"Historial" Timeline
First of all, I would say I am the one who needs to take the blame. :-)
Because, during Germany F2F, Paco suggested to park the discussion of
Issue 111.1 until we have a better idea of how Issue 111 (extension
activity) looks like. At that time, for a moment, I was considering to
say "yes" to Paco's suggestion. However, I made a snap judgement call
to continue the discussion process of Issue 111.1 at the F2F
Now taking in more of design consideration for Extension Activity
(Issue 111), it shows that my snap judgment call in terms of continuing
the discussion at F2F is definitely NOT a good one. I should let the TC
(including myself) have more time to consider more aspects of extension
syntax issue. So, we may not need to re-touch the extension syntax
issue for extension activity.
Technical analysis
For syntax part of Issue 111, we spent most of our
time in arguing whether we add wrapper to <xsd:any> for existing
extension elements (under "tExtensibleElements") or to <xsd:any>
for those relative newer extension points (e.g. new assign operation).
At that time, it seemed to some of us that this decision choice is a
relatively arbitrary one. It looks like that it would just make some
cosmetic or syntactic sugar differences, one way or the other.
Reality is: there are no extra complication / consideration for new
assign operation or literal-from-spec. Because, there are no BPEL
standard elements or standard attributes defined on those new assign
operations or literal-from-spec.
But, now we are trying to solve the syntax issue for Issue 111. We need
to decide where to put those standard attributes (e.g "name" /
"suppressJoinFailure") or standard elements (e.g. <sources> and
<targets>).
Oblivously, we have only 3 choices as listed in the web ballot. Here
are some comparision of these different choices:
Consistent XPath/XSLT Design
The advantage of [Option #1] and [Option #3] is: it
would be MUCH EASIER to write XPath or XSLT to look for those
standard-attributes and stardard-elements. (This advantage is partially
applied to [Option #3] only, excluding the standard-elements part).
Because, we will have a
consistent place to look for those standard-attribute / elements.
For example, "./bpel:flow/*/@name"
This XPath will allow me to retrieve the list of all activity names
within a <bpel:flow> in case of [Option #1] and [Option #3].
However, it will not work for [Option #2], if
<extensibleActivityWrapper>
is used.
XPath / XSLT is important here because they are commonly used in source
code analysis for BPEL developement tool and management console.
Consistent BPEL Activity Syntax
On the other hand, [Option #2] is better than [Option #3], because it
yields a more consistent syntax between a BPEL standardized activity
and an Extension Activity. A consistent syntax is better because:
- If the next version of BPEL spec decides to standardize some of
extension activity, people just need to change their corresponding
XMLNS declaration and remove <extensibleActivityWrapper>. Then
they are done with their code migration to new version of the spec.
(Removal of <extensibleActivityWrapper> is even not needed for
[Option #1].)
- Also, please note that are some subtle differences of location
of
xsd:any between [Option #3] and a standard-activity. That difference
was
first mentioned by Yaron:
http://lists.oasis-open.org/archives/wsbpel/200503/msg00209.html
That difference matters when people try to extend an extension
activity. (Details see below) That difference is definitely
undesirable.
If one looks like closely, actually BOTH advantages of "Consistent
XPath/XSLT Design" and "Consistent BPEL Activity Syntax" can
be applied to [Option #1]. If we pick [Option #1], we can get best of
both world!!!
That is why we decide to pursue [Option #1] by listing it as one of
web-ballot options, after we obtain more pro-vs-cons analysis result as
we progress in Issue 111.
Thank you so much for your understanding !!!
Regards,
Alex Yiu
Alex Yiu wrote:
Hi all,
Here is the details of the web ballot (proposed) for Extension Activity
Syntax.
The
web-ballot is NORMATIVE. That is, a binding vote
on a partial solution for 111 which would then constrain the remaining
completion of the resolution. Similar to what we did with 82 where we
approved a partial solution that set a direction and filled in the
details later with a vote on the additions.
In short, we shall finish the actual proposal for Issue
111 to vote based on the result of this web-ballot.
(I hope the color scheme make it easier for comparision)
Option #1: moving the extension to wrapper to generic extension
points (<extendedBy>)
-----------------------------
<sequence>
<extendedBy>
<foo:sequenceExtension1="xyz"
/>
</extendedBy>
...
<invoke name="myInvoke"
foo:activityExtension2="abc"
operation="op1" ...>
<extendedBy>
<foo:activityExtension3>def</foo:activityExtension3>
</extendedBy>
<targets> ... </targets>
<sources> ... </sources>
</invoke>
<bar:myInvoke name="myExtendedInvoke"
foo:activityExtension2="abc"
operation="op1" ...>
<extendedBy>
<foo:activityExtension3>def</foo:activityExtension3>
</extendedBy>
<targets> ... </targets>
<sources> ... </sources>
</bar:myInvoke>
</sequence>
-----------------------------
Related to: http://lists.oasis-open.org/archives/wsbpel/200503/msg00040.html
Option #2: Using <extensibleActivityWrapper> and having
all
standard attribute and elements and generic extension points (both attr
and elem) local to the extended activity element itself (i.e.
<bar:myInvoke>).
-----------------------------
<sequence>
<foo:sequenceExtension1="xyz"
/>
...
<invoke name="myInvoke"
foo:activityExtension2="abc"
operation="op1" ...>
<foo:activityExtension3>def</foo:activityExtension3>
<targets>
... </targets>
<sources>
... </sources>
</invoke>
<extensibleActivityWrapper>
<bar:myInvoke name="myExtendedInvoke"
foo:activityExtension2="abc"
operation="op1" ...>
<foo:activityExtension3>def</foo:activityExtension3>
<targets>
... </targets>
<sources>
... </sources>
</bar:myInvoke>
</extensibleActivityWrapper>
</sequence>
-----------------------------
Option #3: Using <extensibleActivityWrapper> and having
all
standard attribute and elements and generic extension attr on the
wrapper,
but having generic extension element local to the extended activity
element itself (i.e. <bar:myInvoke>)
-----------------------------
<sequence>
<foo:sequenceExtension1="xyz"
/>
...
<invoke name="myInvoke"
foo:activityExtension2="abc"
operation="op1" ...>
<foo:activityExtension3>def</foo:activityExtension3>
<targets> ... </targets>
<sources> ... </sources>
</invoke>
<extensibleActivityWrapper name="myExtendedInvoke"
foo:activityExtension2="abc">
<targets> ... </targets>
<sources> ... </sources>
<bar:myInvoke
operation="op1" ...>
<foo:activityExtension3>def</foo:activityExtension3>
</bar:myInvoke>
</extensibleActivityWrapper>
</sequence>
-----------------------------
Option #4: Other:
Please state your alternative opinion. E.g.: you can simply state
your position, if you don't support extension activity in general in
BPEL.
Thanks so much!!!
Regards,
Alex Yiu
|