Hi all,
Just want to keep a record in email archive for future reference:
In today conf call, we passed the following proposal for Issue 242:
Issue 242 is closed without change. (That is, we do not
collapse <onEvent> and <scope> syntax. Instead, we choose
the
"extend-by-containment" approach.)
Thanks!
Regards,
Alex Yiu
Alex Yiu wrote:
Cross posted this discussion to Issue 242 as well for future references.
Regards,
Alex Yiu
-------- Original Message --------
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
|