Hi Danny,
Please note that: the link structure are always under the BPEL's
namespace (not the "bar" namespace). Therefore, a BPEL parser/compiler
can easily recognize the link structure by just the namespace itself.
Moreover, whenever an BPEL source-code tree-fragment can match xsd:any
designed for extended activity (as specified in their corresponding
XSD), that fragment must be an extended activity. (Remember we are
trying to create a non-ambigous grammar here). Since it must be an
extended activity, the relative locations of link-structure construct
and its physical appearance (e.g. <bpel:target>
<bpel:source>) are well defined, even one do not know the
detailed definition of the matched extended activity. That is, BPEL
analysis logic (e.g. dealing with link structure) would have NO problem
to retrieve those link related fragments out of the extended activity.
Another thing to mention is: the inconsistency of the locations of
element-based extension placed within extended activity (illustrated in
the web ballot already) between Option #3 and a standard activity. That
kind of inconsistencies worry me.
(As mentioned by Yaron: http://lists.oasis-open.org/archives/wsbpel/200503/msg00209.html)
Also, in [Option #1], all the standard attribute/elements (e.g. links)
and extension attribute/elements of an extended activity are exactly in
the same location compared to a BPEL standard activity. Actually, I
would argue that it is easier to write BPEL source analysis logic
(including preserve the link structure AND interpreting extension
element) with [Option #1]. Because, the same logic can be used to deal
with both standard activity and extended activity. It is much less
likely to have bugs in BPEL source analysis logic.
(No more "Got you ... syntax structure of an extended activiy
are actually different from a standard activity" kind of errors ...
again the story here is similar to JSP taglib )
[*** XSD Details Ahead:
If we pick
using XSD concept to describe the syntax constraint of an extended
activity in the main Issue 111 proposal:
In the case of [option #1] and [option #2], I am expecting the extended
activity construct must be valid to an extended type of
"bpel:tActivity" type (just like other standard activity, e.g.
<bpel:invoke>).
For [option #3], the wrapper will be a restricted type of "tActivity"
(intead of extended type) and the XSD type to describe content inside
the wrapper will be something brand new ... and I am still struggling
whether I can come with a sensible one ... given the complex nature of
<xsd:any> and BPEL extension.
***]
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
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
---------------------------------------------------------------------
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
|