[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Re: Macros? (was RE: [wsbpel] Issue - 143 - StaticSwitchActivity)
The utility of if, until, for-each and static switch is more than proven by their near universal support across just about every procedural language in existence. So by any reasonable standard they pass the 'must be there' test with flying colors. They are especially critical to BPEL since our main value add is that we are portable. If we don't provide these structures as first class members of BPEL then BPEL editors will have to simulate them. This will render portability meaningless as something that looks like a 'for-each' in one BPEL editor will be an unintelligible and unmaintainable mass of whiles and assigns in another editor. So both on utility and portability these are must haves. Yaron > To: <ygoland@bea.com>, <edwin.khodabakchian@oracle.com> > cc: <wsbpel@lists.oasis-open.org> > Subject: RE: [wsbpel] Re: Macros? (was RE: [wsbpel] Issue - 143 - > StaticSwitch Activity) > > > +1 on a couple of points from Edwin > > A. Follow Yaron's precept of "don't (propose to) add stuff if it > doesn't absolutely have to be there" (my paraphrase) :-) And justify > why it absolutely has to be there if you propose it. > > B. The ability to invent useful macros is infinite. We should not open > the floodgates. > > Satish > > > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Friday, July 16, 2004 10:27 AM > To: edwin.khodabakchian@oracle.com > Cc: wsbpel@lists.oasis-open.org > Subject: [wsbpel] Re: Macros? (was RE: [wsbpel] Issue - 143 - > StaticSwitch Activity) > > I'm not sure how you are distinguishing between a visualization/notation > > problem and a core function. Could you further elucidate the dividing > line? > > Thanks, > Yaron > > Edwin Khodabakchian wrote: > > > > > > > Yaron, > > > > Portability would be affected if you believe that vendors will start > > extending the language to support trivial things such as a > staticSwitch. It > > could very well be that the difference between staticSwitch and switch > are > > handled at UI/visualization layer (if at all). > > > > We might consider postponing all those macros until the > > visualization/notation problem is addressed (which I believe is not in > the > > scope of V1). > > > > -Edwin > > > > -----Original Message----- > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > Sent: Thursday, July 15, 2004 1:57 PM > > To: edwin.khodabakchian@oracle.com > > Cc: wsbpel@lists.oasis-open.org > > Subject: Re: Macros? (was RE: [wsbpel] Issue - 143 - StaticSwitch > Activity) > > > > I believe customers expect BPEL to provide them with real portability. > > That's why they like BPEL. Protecting their core control structures is > a > > key part of providing that portability and why I think these > structures > > need to be in V1. > > > > Yaron > > > > Edwin Khodabakchian wrote: > > > > > > > > > > > Hi Yaron! > > > > > > > > > > > > Interesting bursts of issues! How to the macro concept fit with > your "a > > > spec is complete when everything that can be removed has been > removed > > > criteria"? The challenge with macros is that they end up being a > matter > > > of taste. Also a simpler solution might actually be to let v2 of > the > > > language to have explicit support for macros so that people can > create > > > their own set without polluting the core of the language. > > > > > > > > > > > > Just some thoughts. > > > > > > > > > > > > Edwin > > > > > > > > > > > > * From: * ws-bpel issues list editor > > [mailto:peter.furniss@choreology.com] > > > *Sent:* Wednesday, July 14, 2004 7:01 PM > > > *To:* wsbpel@lists.oasis-open.org > > > *Subject:* [wsbpel] Issue - 143 - StaticSwitch Activity > > > > > > > > > > > > This issue has been added to the wsbpel issue list. The issues list > is > > > posted as a Technical Committee document to the OASIS WSBPEL TC > pages > > > <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a regular > > > basis. The current edition, as a TC document, is the most recent > version > > > of the document entitled in the "Issues" folder of the WSBPEL TC > > > document list > > > <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> > - > > > the next posting as a TC document will include this issue. The list > > > editor's working copy, which will normally include an issue when it > is > > > announced, is available at this constant URL > > > <http://www.choreology.com/external/WS_BPEL_issues_list.html>. > > > > > > > > > * Issue - 143 - StaticSwitch Activity * > > > > > > * Status: * open > > > *Categories:* Syntax and validation > <#category_syntax_and_validation> > > > *Date added:* 15 Jul 2004 > > > *Submitter:* Yaron Y. Goland <mailto:ygoland@bea.com> > > > *Date submitted:* 15 July 2004 > > > *Description:* A static switch is a switch in which the values of > the > > > cases are static values rather than expressions. Besides being a > common > > > form of switch it is an easily validated expression for providing > > > control flow over enumerated values. > > > *Submitter's proposal:* > > > > > > > > > > > > <staticSwitch standard-attributes> > > > > > > standard-elements > > > > > > <condition expression-language="URI">general-expr</condition> > > > > > > > <case value="xs:string">+ > > > > > > activity > > > > > > </case> > > > > > > <otherwise> > > > > > > activity > > > > > > </otherwise> > > > > > > </staticSwitch> > > > > > > This is effectively a macro for: > > > > > > > > > > > > <switch> > > > > > > <case>+ > > > > > > <condition>general-expr = string</condition> > > > > > > activity > > > > > > </case> > > > > > > <otherwise> > > > > > > activity > > > > > > </otherwise> > > > > > > </switch> > > > > > > > > > *Changes:* 15 Jul 2004 - new issue > > > > > > To comment on this issue, please follow-up to this announcement on > the > > > wsbpel@lists.oasis-open.org list (replying to this message should > > > automatically send your message to that list), or ensure the > subject > > > line as you send it *starts* "Issue - 143 - [anything]" or is a > reply to > > > such a message. If you want to formally propose a resolution, > please > > > start the subject line "Issue - 143 - Proposed resolution", without > any > > > Re: or similar. > > > > > > To add a new issue, see the issues procedures document (but the > address > > > for new issue submission is the sender of this announcement). > > > > > > To unsubscribe from this mailing list (and be removed from the > roster of > > > the OASIS TC), go to > > > > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr > oup. > > > > php. > > > > > > > From - Fri > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr > oup.php. > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php > > . > > > > > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]