Re: [wsbpel] Issue - 63 - Support of Array

["Mark Little" <mark.little@arjuna.com>]

Again on behalf of Jim Webber.

Mark.

> -----Original Message-----
> From: Jim Webber [mailto:jim.webber@arjuna.com] 
> Sent: 16 September 2003 16:46
> To: 'Ricky Ho'
> Subject: RE: [wsbpel] Issue - 63 - Support of Array
> 
> 
> Ricky:
> 
> The Person[] in any given C-like programming language is a 
> shorthand for the declaration of many objects of type Person. 
> It is not a true data structure, though it is often (ab)used 
> as such. Better to have Array<Person&> which to my mind is 
> the XML Schema approach.
> 
> Jim
> 
> PS - Same deal with this message, if you could CC your 
> replies to the BPEL list?
> 
> > -----Original Message-----
> > From: Ricky Ho [mailto:riho@cisco.com]
> > Sent: 16 September 2003 16:40
> > To: Jim Webber
> > Subject: RE: [wsbpel] Issue - 63 - Support of Array
> > 
> > 
> > Did the two code segment I respond to you previously show the
> > complexity 
> > when array is not supported ?
> > 
> > If so, then the question whether it justify the introduction
> > of "Array".  I 
> > certainly don't think this is "create a new type system in 
> > BPEL" and I 
> > think this extension is very minimal.  Just look at programming 
> > language.  Array is not considered as a new type.  e.g If 
> you have a 
> > "Person" class, you automatically have "Person[]" without 
> > explicitly define it.
> > 
> > Rgds, Ricky
> > 
> > At 10:03 AM 9/16/2003 +0100, Jim Webber wrote:
> > >Ricky:
> > >
> > >[Appologies for this coming only to you, I've been downgraded to an
> > >observer because of an unfortunate mix of vacation time and telcon 
> > >dates. If you could forward your response to the main list, 
> > that'd be
> > >cool.]
> > >
> > > > Compare this with the other case where the seller need to handle
> > > > multiple purchase orders.  Now without array support in 
> BPEL, you 
> > > > need to create a
> > > > new complex type to represent multiple purchase order.
> > >
> > >Yes, in that case you are right, but I think it is simpler
> > to keep the
> > >type system entirely within XML Schema. No point in layering
> > a second
> > >type system on the top of it in BPEL. Of course we could 
> define some
> > >BPEL standard types and mandate the semantics of those type w.r.t 
> > >particular BPEL operators, but I think that's overkill.
> > >
> > >Also for this situation, would the seller not just receive multiple
> > >purchase orders? In that case the standard <receive> 
> > activity suffices
> > >(though a new process may be kicked off on receipt of each).
> > >
> > >I guess what I'm saying is that there are fairly simple
> > workarounds to
> > >your situation which are consistent with the look-and-feel
> > of BPEL. I
> > >think the array solution is trying to bash a square peg 
> into a round
> > >hole.
> > >
> > >Jim
> > 
> > 
>