+1
But can’t we just eliminate the
messageType and element declarations in the onEvent element entirely rather
than deprecate something which hasn’t been released yet?
- Chris
From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Tuesday, March 07, 2006 2:32
PM
To: wsbpeltc
Subject: Re: [wsbpel] Issue 241 -
Proposal for Vote
+1
We could also consider deprecating the declaration that is NOT in the
associated scope. In other words, keep it in the spec, but alert users
that it's mostly there for backwards compatibility.
Danny
Dieter Koenig1 wrote:
This
suggestion is related to 241 and 204.
For more consistency across event handlers and forEach, if we allow
variables to be declared in the EH's associated scope:
"For cross-reference redundancy and clarity, these variables referenced by
variable attribute or <fromPart> element may be optionally declared in
the
associated scope explicitly. If explicitly declared, variable types used in
declaration MUST be exact matches of the correponding definitions in
WSDL."
then it would make sense to allow the optional explicit declaration of a
counter variable (in a scope associated with forEach) as well.
Any opinion?
Kind Regards
DK
Alex
Yiu
<alex.yiu@oracle.
com>
To
wsbpeltc
07.03.2006 05:44 <wsbpel@lists.oasis-open.org>
cc
Alex Yiu <alex.yiu@oracle.com>,
Danny van der Rijn
<dannyv@tibco.com>, Mark
Ford
<mark.ford@active-endpoints.com>
Subject
[wsbpel] Issue 241 - Proposal for
Vote
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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