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 241 - Proposal for Vote


Title: Re: [wsbpel] Issue 241 - Proposal for Vote
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


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