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]
