OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue 242 - Proposal passed



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 --------
Subject: [wsbpel] Re: Issue 241 - Proposal draft
Date: Tue, 28 Feb 2006 19:50:37 -0800
From: Alex Yiu <alex.yiu@oracle.com>
To: Alex Yiu <alex.yiu@oracle.com>
CC: Danny van der Rijn <dannyv@tibco.com>, wsbpeltc <wsbpel@lists.oasis-open.org>, Mark Ford <mark.ford@active-endpoints.com>
References: <43FBF342.2000509@oracle.com> <43FCB48E.8070809@tibco.com> <43FCBEE1.3030204@oracle.com>



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






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]