execution engine or programming language?

["Edwin Khodabakchian" <edwink@collaxa.com>]

Yaron,
Is HTML an execution engine or a programming language?
Edwin 

> 
> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com] 
> Sent: Tuesday, June 24, 2003 1:02 PM
> To: Assaf Arkin; Jim Webber
> Cc: fred.carter@amberpoint.com; 'Ron Ten-Hove'; 
> wsbpel@lists.oasis-open.org
> 
> So Spake Assaf
> > If the language is intended purely for an engine, then you 
> remove the 
> > redundant constructs for which you have to develop documentation, 
> > code, test cases, etc. If the language is also used for XML 
> authoring 
> > then you actually introduce more constructs to make XML 
> authoring easy
> > -- another form of optimization.
> 
> +1
> 
> The group needs to clearly and consistently decide on the 
> question - Are BPEL executable processes an execution engine 
> or a programming language?
> 
> Only with clarity on that issue can we hope to resolve issues 
> like this one.
> 
> 		Yaron
> 
> > -----Original Message-----
> > From: Assaf Arkin [mailto:arkin@intalio.com]
> > Sent: Saturday, June 21, 2003 7:59 PM
> > To: Jim Webber
> > Cc: fred.carter@amberpoint.com; 'Ron Ten-Hove'; 
> > wsbpel@lists.oasis-open.org
> > Subject: Re: [wsbpel] implicite links of the runtime engine
> >
> >
> > Jim Webber wrote:
> >
> > >Guys,
> > >
> > >
> > >
> > >>My counter argument is that you need to build support for 
> > >>serializing activities that synchronize through links. 
> It's not an 
> > >>easy task, but you'll have to do it anyway. If you 
> already spent the 
> > >>time making flows work properly, might as well use that piece of 
> > >>code in all cases. If you write it once and use it all over the 
> > >>place then there's a good ROI argument in favor of using 
> <flow> as 
> > >>much as possible. Less code to develop, less test cases, etc. At 
> > >>least from an execution perspective.
> > >>
> > >>
> > >
> > >After having hand written BPEL scripts, and intending to do so in 
> > >future (because sometimes you just have to do things for 
> yourself), I
> > would plead
> > >the case for keeping useful bits of syntactic sugar like <flow>.
> > For those
> > >of us who will be writing BPEL by hand (and I might be a 
> minority of 
> > >one
> > >here) other constructs like <macro> or <procedure> would be very 
> > >welcome too.
> > >
> > >The point is, although I can see that tools are really useful in
> > this arena,
> > >there will always be cases where tools aren't applicable. 
> Given that 
> > >BPEL hasn't been used much so far, it is premature to start 
> > >optimising away features that I (for one) might rely on!
> > >
> > >
> > Optimization is not necessarily about removing features but 
> reducing 
> > cost. If the language is intended purely for an engine, then you 
> > remove the redundant constructs for which you have to develop 
> > documentation, code, test cases, etc. If the language is 
> also used for 
> > XML authoring then you actually introduce more constructs 
> to make XML 
> > authoring easy
> > -- another form of optimization.
> >
> > So if we made a conscious decision to support authoring I 
> do think we 
> > need <sequence> and also something of the like of 
> <procedure>. But I 
> > think we're better off if we have one standardized way to 
> write macros 
> > that we can use in a variety of specifications, including 
> but not just 
> > BPEL.
> >
> > arkin
> >
> > >Jim
> > >
> > >
> > 
> >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> > >For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> > >
> > >
> >
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> 
>