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] Re: Macros? (was RE: [wsbpel] Issue - 143 - StaticSwitch Activity)


Portability never applies to macros - only to their expansion.

And let us be clear that we are not designing a full fledged programming
language here.  Otherwise we will need to make a pretty large expansion
of our feature set and we would no longer be interesting to most
customers, who are not looking for another programming language.
Therefore "this is in Java and C# and Pascal and Ada therefore it should
be in BPEL" is not a conclusive argument for "must have".

I am not commenting here on any or all of the specific proposals.  For
instance, the parallel for-each is definitely interesting.  I simply
don't want to let pass arguments that could send us down a very slippery
slope.

Satish

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Tuesday, July 20, 2004 3:19 PM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Re: Macros? (was RE: [wsbpel] Issue - 143 -
StaticSwitch Activity)

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_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_workgr
oup.php. 
> 
> 




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