Subject: Re: [wsbpel] Issue - 111 - Syntax Choices for Extension Activity(Web Ballot) [background for option#1]
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]
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.
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:
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 !!!
Alex Yiu wrote: