|
I
think there are two issues here. The first is an important clarification of
<fromPart> and how it is used within an onEvent.
The <fromPart> is mutually exclusive with the variable
attribute. This applies to the messageType and element attributes as well
(as pointed out in Alex's proposal). The problem I have is that both the
draft specification and Alex's proposal contain language that has the parts in
the <fromPart> being manifested as implicit variables within the
associated scope. I think this violates the spirit of the <fromPart>
element. The parts should not be manifested as explicit variables. The data
received by the IMA goes into an anonymous temporary WSDL variable. It is simply
a container for data that can only be accessed by the <fromPart> element.
Manifesting the parts of this temporary variable as implicit variable
declarations of the appropriate type seems unnecessary and undesirable. It is
unnecessary since the data from the variable will be copied into a target
variable that is within scope, therefore if you need to access the data then
read from the designated toVariable. It is undesirable since the manifestation
of these parts as implicit variables could serve to hide other variables with
the same names that would otherwise be in scope and accessible to the associated
scope.
The other issue is whether or not the messageType and element attributes
should exist on the <onEvent>
I think that this is a matter of style
more than functionality. Using the messageType or element attribute for
onEvent is not consistent with the other IMA's (although it is consistent
with a <catch>). In the other IMA's you need to resolve the variable in
order to determine what type of variable pattern is being used. I would
argue that the same logic should apply here. I don't think we need new
attributes in order to provide the hint.
Hi DK, Mark, Danny, Chris and others,
For rest of
Issue 241 discussion, I am going to spilt into two email threads:
(a)
Whether to allow optional explicit declaration and its implication to
<forEach>
(b) Whether to remove messageType and element from
<onEvent>
(That is *this* email thread)
For (b): Whether to remove messageType and element attr from
<onEvent>
[Mark and Chris, I think I can understand your intention
from you guys more clearly after reading the email for the second
time.]
There are a few important notes to mention:
- A reminder: this issue has already been decided in our previous
directional vote on Issue 241. We have voted in directional vote: we will do
implicit variable declaration.
- The "messageType" / "element" attributes in <onEvent> exist mainly
because we support two different patterns to use a single variable to receive
an inbound message:
(i) a messageType variable (ii) an element variable
for single doc-lit message.
If we did not have support for these two
patterns, we would not need "messageType" / "element" attributes at all in
<onEvent>. Because, we can always deduce the messageType. So,
"messageType" and "element" attribute are not for type declaration per see. It
is more like an indicator which variable pattern is being used.
- Say, if we drop messageType and element attr from <onEvent>, that
will essentially ask users to declare those variables explicitly in the
associated scope. I think it is against our intention determined by our
directional vote last week.
- And, more importantly, how do we handle the cases of <fromPart>, if
we drop messageType and element attr? Are we going to ask users to declare all
these part variables in the associated scope explicitly also? If users are not
required, then we got some strange asymmetry between <fromPart> usage
pattern and other variable usage patterns. If users are required to declare,
then we got a violation of DRY principle (Don't Repeat Yourself) and usability
issue.
Therefore, I tend to say, we should keep "messageType"
and "element" attr in <onEvent>.
Please let me know any further
opinion preferences from you guys soon.
Thanks!
Regards,
Alex Yiu
Danny van der
Rijn wrote:
I wasn't sure how
well that would go over, so I didn't suggest it. But now that Chris did,
a hearty +1 from me.
Chris Keller wrote:
+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
---------------------------------------------------------------------
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
|