[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Issue 241 - Proposal draft
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):
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]