even so, if we add the ability to have assign create new nodes (issue 11),
then this syntax wouldn't work.
----- Original Message -----
From: "Maciej Szefler" <>
To: "Danny van der Rijn" <>; "wsbpeltc"
<>
Sent: Friday, March 12, 2004 9:52 AM
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 <>
> 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" <>
> > To: "Maciej Szefler" <>; "Dieter Roller"
> > <>
> > Cc: "Alex Yiu" <>; "Assaf Arkin" <>;
> > "wsbpeltc" <>; <>
> > 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:]
> > Sent: Friday, March 12, 2004 8:47 AM
> > To: Dieter Roller; Satish Thatte
> > Cc: Alex Yiu; Assaf Arkin; wsbpeltc;
> > 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 <>
> > wrote:
> >
> >>
> >>
> >>
> >>
> >> +1
> >>
> >> Cheers,
> >>
> >> dieter
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> "Satish Thatte"
> >> <satisht@microsof
> >> t.com>
> >
> >> To
> >> "Assaf Arkin"
> > <>,
> >> 03/12/2004 05:14 "Alex Yiu"
> > <>
> >> AM
> >
> >> cc
> >> "wsbpeltc"
> >> <>,
> >> <>
> >>
> > 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:]
> >> Sent: Thursday, March 11, 2004 7:59 PM
> >> To: Alex Yiu
> >> Cc: wsbpeltc; Satish Thatte;
> >> 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]
>
> 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.
>
