Hi all,
Here is the formal proposal for voting for Issue 241:
PDF version: (9 page)
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/17023/wsbpel-specification-draft.241_proposal_v2b.pdf
MS-Word version: (9 page of changes on top of whole spec)
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/17024/wsbpel-specification-draft.241_proposal_v2b.doc
90% of changes are same as the draft that I sent out last week with
some extra clarification and cleaning up syntax in the direction of
voting decision of Issue 242.
Please let me know ahead of time, if you guys have any idea of friendly
amendments or fine-tuning of wordings.
Thanks!
Regards,
Alex Yiu
Alex Yiu wrote:
Hi all,
Here is the proposal draft for Issue 241.
PDF version of 9 pages which contain the changes
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/16945/wsbpel-specification-draft.241_proposal_draft.pdf
MS-Word version of changes applied to the whole spec text (based on a
very recent version from CVS):
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/16944/wsbpel-specification-draft.241_proposal.doc
Note:
[1]
One more normative changes we need to make (but not a part of the PDF)
is to amend/clarify resolution of Issue 123 in a very minor way as
follow:
From: "This resolution follows the same scoping rules as variable and
correlationSet resolution."
To: "This resolution follows the same scoping rules as correlationSet
resolution."
[2]
In this proposal, I did try to clean up some syntactic issue of
<onEvent> not directly related to issue 242. (e.g. making
variable attribute optional because of <fromPart>).
I do intend to come up a consolidated proposal based on the
(directional) decision of Issue 242. Because there are a number of
places in desc text of <onEvent> (not just syntax) needs to be
fine-tuned a bit more after syntactic decisions are made. Here are two
syntactic decisions need to be made:
[a] moving <correlationSets> "inline" declaration to the
associate scope (regardless of decision of [b] below: whether the
associated scope is collapse into <onEvent>). [Currently, I tend
to say we should move declaration to make the syntax more consistent
with other scope-related syntax]
[b] core decision for Issue 242: whether to collapse scope
syntax into <onEvent> syntax. Namely, we have 3 choices here:
(i) Yes, we collapse. The syntax is based XSD extend. Example:
---------------------------
<onEvent ... partnerLink="..."
variable="..."
isolated="..." name="...">
<partnerLinks> ... </partnerLinks>
<variables> ...
</variables>
<correlationSets> ... </correlationSets>
...
main activity
<correlations> ...
</corelations>
<fromPart ... />*
</onEvent>
---------------------------
(ii) Yes, we collapse. Its syntax is NOT derived scope. (That
means we need to main a separate, duplicated, different and yet similar
grammar rule.) Example:
---------------------------
<onEvent ... partnerLink="..."
variable="..."
isolated="..." name="...">
<correlations> ...
</corelations>
<fromPart ... />*
<partnerLinks> ...
</partnerLinks>
<variables> ... </variables>
<correlationSets> ... </correlationSets>
...
main activity
</onEvent>
---------------------------
(iii) No. We do not collapse. Instead, we choose the
"extend-by-containment" approach. Example:
---------------------------
<onEvent ... partnerLink="..."
variable="...">
<correlations> ...
</corelations>
<fromPart ... />*
<scope ...
isolated="..." name="...">
<partnerLinks> ... </partnerLinks>
<variables> ... </variables>
<correlationSets> ... </correlationSets>
...
main activity
</scope>
</onEvent>
---------------------------
Further analysis (from my viewpoint):
- The main reason that I heard from proponents of collapse seems
to
be elminiating forward-reference pattern (i.e. a resource is declared
after reference in source code order). IMHO, that is a commonly used
situation in a lot of programming language. Furthermore, you can see
later that this situation cannot be elminated even if we decide to
collapse those syntax.
- The syntax order in (i) just seems very odd and unnatural and
make the source code visualization much harder. And, forward-reference
still happens for variable and partnerLink.
- For the syntax in (ii), forward-reference still happens for
variable and partnerLink. The interleaving syntax (highlighted blue and brown)
make it harder for people to learn and remember what is exactly
<onEvent> is about. Moreover, we will be forced to duplicated
grammar rule for tScope for no compelling reasons. Make BPEL source
code syntax analyser implementation more difficult.
- For the syntax in (iii), I personally prefer the most. Because,
the syntax groups syntax common to <scope> and specific to
<onEvent> in a clean and easy-to-learn way. <onEvent>
syntax is the outer syntax, while <scope> is the inner syntax. It
does not require any XSD grammar rule duplication. And, it makes use of
another common and useful design pattern - "extend-by-containment".
Ideally, I want to submit a proposal (potentially with Danny) that
resolve both Issue 241 and 242. That will minimize any risk
inconsistent and "leftover" editing issue in that section.
[3]
For Issue 245, assuming it is opened. I agree with Danny and Mark
there. This proposal draft contains an attempt to clean up Section
12.5.7 which is also a part of "Event Handlers" section.
Thanks!
Regards,
Alex Yiu
|