[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 103 - Good Idea!
This might not be a problem if it were possible to define copy assignment in terms of node-replacement operations; then any expression that returns a node could act as an l-value to an assignment. Such a scheme could rely exclusively on schema-based type checking (with an implied schema for message variables). -maciej On Fri, 12 Mar 2004 09:12:04 -0800, Danny van der Rijn <dannyv@tibco.com> wrote: > i wouldn't think so, since $var refers to the value, not the location. > but > being just a mere mortal, i am open to being corrected. > > ----- Original Message ----- > From: "Satish Thatte" <satisht@microsoft.com> > To: "Maciej Szefler" <mbs@fivesight.com>; "Dieter Roller" > <ROL@de.ibm.com> > Cc: "Alex Yiu" <alex.yiu@oracle.com>; "Assaf Arkin" <arkin@intalio.com>; > "wsbpeltc" <wsbpel@lists.oasis-open.org>; <ygoland@bea.com> > Sent: Friday, March 12, 2004 8:52 AM > Subject: RE: [wsbpel] Issue 103 - Good Idea! > > > I imagine that expression= is as relevant to "to" as to "from" .. > > -----Original Message----- > From: Maciej Szefler [mailto:mbs@fivesight.com] > Sent: Friday, March 12, 2004 8:47 AM > To: Dieter Roller; Satish Thatte > Cc: Alex Yiu; Assaf Arkin; wsbpeltc; ygoland@bea.com > Subject: Re: [wsbpel] Issue 103 - Good Idea! > > I haven't followed this discussion too closely, but am I correct in > inferring that if these suggestion were adopted, we could eliminate most > > of the from-specs in the assign activity? Could we normalize assignment > to > the following > > <copy> > <to variable="msgVar"/> > <from expression="$otherMsgVar"/> > </copy> > > could be used to assign a message variable. > > <copy> > <to variable="simpleTypeVar"/> > <from expression="$msgVar/msg/simplePart"/> > </copy> > > <copy> > <to variable="simpleTypeVar"/> > <from expression="$otherSimpleTypeVar"/> > </copy> > > could be used to assign a simple variable > > <copy> > <to variable="elementVar"/> > <from expression="$msgVar/msg/elementPartType"/> > </copy> > <copy> > <to variable="elementVar"/> > <from expression="$otherElementVar"/> > </copy> > > could be used to assign an element variable. > > -maciej > > > > > On Fri, 12 Mar 2004 07:23:35 +0100, Dieter Roller <ROL@de.ibm.com> > wrote: > >> >> >> >> >> +1 >> >> Cheers, >> >> dieter >> >> >> >> >> >> >> >> >> "Satish Thatte" >> <satisht@microsof >> t.com> > >> To >> "Assaf Arkin" > <arkin@intalio.com>, >> 03/12/2004 05:14 "Alex Yiu" > <alex.yiu@oracle.com> >> AM > >> cc >> "wsbpeltc" >> <wsbpel@lists.oasis-open.org>, >> <ygoland@bea.com> >> > Subject >> RE: [wsbpel] Issue 103 - Good >> Idea! >> >> >> >> >> >> >> >> >> >> >> I am having trouble keeping up with this fast moving discussion. I am >> hoping that you will reach an agreement and then educate the mere >> mortals among us on what the consensus proposal is .. >> >> Satish >> >> >> >> -----Original Message----- >> From: Assaf Arkin [mailto:arkin@intalio.com] >> Sent: Thursday, March 11, 2004 7:59 PM >> To: Alex Yiu >> Cc: wsbpeltc; Satish Thatte; ygoland@bea.com >> Subject: Re: [wsbpel] Issue 103 - Good Idea! >> >> >>> (4) >>> Assaf suggested: >>> In WSDL 2.0, >>> $variable/ns:element[/ns:subElement] >>> In WSDL 1.1, >>> $variable/partName/ns:element >>> >>> I was wondering whether it make sense to add a WSDL QNAME >>> (ns:wsdlMsgName) like the following for WSDL 1.1: >>> >>> $variable/ns:wsdlMsgName/partName/... >>> >>> then the syntax would be more symmetrically between WSDL 1.1 and 2.0 >>> ns:wsdlMsgName => ns:element >>> partname => subElement >>> >>> The BPEL code migration may be easier from WSDL 1.1 to 2.0 >> >> If anyone has a good handle on where WSDL 2.0 is heading with their >> message definition, would be great to throw some ideas around. Ideally >> if you have a WSDL 2.0 interface that's backward compatible with WSDL >> 1.1, you could use the BPEL process with both 1.1 and 2.0 without >> change. >> >> Assaf >> >> >> >> 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. >> > > > -- Maciej Szefler [mbs(a)fivesight.com] [+1-312-432-0556x226]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]