OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Fw: [wsbpel] Issue - 157 - conf call brief recap ... and carryforward ...


Hi Alex,

to explain my point:
 From an XML point of view  'replace element name' seems to mean replace 
the name of the copied element with that of the *target*

how about renaming the attribute to 'retainSourceElementName' or 
something like that that is clearer in terms of direction that 
'replaceElementName'

Regards,
Rania

Alex Yiu wrote:

>
> Hi Rania,
>
> More elaboration on "replaceElementName", if such a feature exist in 
> <copy>:
> ---------------------------
> <assign>
>    <copy replaceElementName="yes|no">
>          <from> ... </from>
>          <to> ... </to>
>    </copy>
> </assign>
> ---------------------------
>
> If replaceElementName="yes", the element name of the target EII 
> pointed by to-spec would be replaced by the element name of source EII 
> pointed by from-spec.
>
> E.g.:
> v1:
> ---------------------------
> <p:poHeader>
>    ...
>    <p:us_shippingAddress verified="true">
>         <p:addressLine1> 123 Main Street </p:addressLine1>
>         ...
>    </p:us_shippingAddress>
>    ...
> </p:poHeader>
> ---------------------------
>
> v2:
> ---------------------------
> <p:poHeader>
>    ...
>    <p:shippingAddress>
>         <p:addressLine1> 456 Market Street </p:addressLine1>
>         ...
>    </p:shippingAddress>
>    <p:billingAddress>
>         <p:addressLine1> 789 Park Ave </p:addressLine1>
>         ...
>    </p:billingAddress>
>    ...
> </p:poHeader>
> ---------------------------
>
> *Example #1*
> ---------------------------
> <assign>
>    <copy replaceElementName="*no*">
>          <from> $v1/p:us_shippingAddress </from>
>          <to> $v2/p:billingAddress </to>
>    </copy>
> </assign>
> ---------------------------
>
>
> After executing the above <assign>, v2 will become:
> ---------------------------
> <p:poHeader>
>    ...
>    <p:shippingAddress>
>         <p:addressLine1> 456 Market Street </p:addressLine1>
>         ...
>    </p:shippingAddress>
>    <p:billingAddress /*verified="true"*/>
>         /*<p:addressLine1> *//*123 Main Street*//* </p:addressLine1>
>         ... */
>    </p:billingAddress>
>    ...
> </p:poHeader>
> ---------------------------
> And "copy-then-equal" holds true in this case, i.e.,
> "$v1/p:us_shippingAddress = $v2/p:billingAddress" is true.
>
>
> *Example #2*
> ---------------------------
> <assign>
>    <copy replaceElementName="*yes*">
>          <from> $v1/p:us_shippingAddress </from>
>          <to> $v2/p:shippingAddress </to>
>    </copy>
> </assign>
> ---------------------------
>
> After executing the above <assign>, v2 will become:
> ---------------------------
> <p:poHeader>
>    ...
> /*   <p:us_shippingAddress verified="true">
>         <p:addressLine1> 123 Main Street </p:addressLine1>
>         ...
>    </p:us_shippingAddress>
> */   <p:billingAddress>
>         <p:addressLine1> 789 Park Ave </p:addressLine1>
>         ...
>    </p:billingAddress>
>    ...
> </p:poHeader>
> ---------------------------
>
> And "copy-then-equal" does NOT hold true in this case, i.e.,
> "$v1/p:us_shippingAddress = $v2/p:shippingAddress" is NOT true.
> (Because, $v2/p:shippingAddress yields zero node after the <assign>.)
>
>
> IMHO, the default of replaceElementName should be "no", if such a 
> feature exist.
>
>
> Thanks!
>
>
>
> Regards,
> Alex Yiu
>
>
>
>
> Rania Khalaf wrote:
>
>> Sorry that's my failed shorthand ;) I meant the sentence about the 
>> copy-the-equal property at the end of Alex's email. When I think of 
>> replaceElementName in a copy, I think of replacing the name of the 
>> copied element by that of the element being copied into.
>>
>
>
> Rania Khalaf wrote:
>
>> Hi Alex,
>> in the last bit, I think you mean if replaceElementName=no then the 
>> copy.. fails . right?
>> r
>>
>> Alex Yiu wrote:
>>
>>>
>>> Hi, Danny, Chris and Rania,
>>>
>>> Well ... I understand the motivation behind the cases of <xs:choice> 
>>> and <xs:any>. However, I would not make them equivalent to the case 
>>> of SG (substitutionGroup). Because, in the case of SG, the from and 
>>> to are still compatible data types. But for case of choice and any, 
>>> they may not be compatible types.
>>>
>>> I definitely still want to keep the "copy-then-equal" for <copy> 
>>> operation (at least for majority of the cases)
>>>
>>> On the other hand, I am still evaluating whether we should support 
>>> element-node-name-replace in <copy> and Issue 157 ...
>>>
>>> **IF** we want to support it, I suppose the syntax will look like this:
>>> ---------------------------
>>> <assign>
>>>    <copy replaceElementName="yes|no">
>>>          <from> ... </from>
>>>          <to> ... </to>
>>>    </copy>
>>> </assign>
>>> ---------------------------
>>>
>>> The case of replaceElementName="yes" would be the ONLY case where 
>>> the "copy-then-equal" property does not hold true. That should be 
>>> stated normatively in the issue resolution text.
>>>
>>>
>>> Thanks!
>>>
>>>
>>> Regards,
>>> Alex Yiu
>>>
>>>
>>> Danny van der Rijn wrote:
>>>
>>>> While I would agree with Chris in a perfect world, we're not 
>>>> dealing in such a world, we're dealing with XML ;-)  To have copy 
>>>> not handle these cases without resorting to issue 11 (which might 
>>>> not pass..) may leave some users very unhappy.
>>>>
>>>> Chris Keller wrote:
>>>>
>>>>> Hi Rania,
>>>>>
>>>>> I agree the use case is more than substitution group.
>>>>>
>>>>> In my mind the issue comes down to whether we are creating a new 
>>>>> path.  If a
>>>>> user identifies <from>$var/x</from><to>$varb/a/b/c</to> should 
>>>>> $varb/a/b/c
>>>>> become $varb/a/b/x when the operation is done.  In my mind it is 
>>>>> better if
>>>>> we describe this operation as leaving the path $varb/a/b/c, but 
>>>>> the contents
>>>>> of $varb/a/b/c has changed.
>>>>>
>>>>> I think the use cases were the element name for the target is 
>>>>> unknown and
>>>>> derived from the source are best left to issue 11 where we should 
>>>>> define a
>>>>> create new node capability (and maybe a rename, but create is the 
>>>>> 80% case).
>>>>> We can put it in 157 as an option on the <to>, but maybe we are 
>>>>> putting too
>>>>> much in 157.
>>>>>
>>>>> - Chris
>>>>>
>>>>> -----Original Message-----
>>>>> From: Rania Khalaf [mailto:rkhalaf@watson.ibm.com] Sent: Thursday, 
>>>>> June 30, 2005 10:36 AM
>>>>> To: Ron Ten-Hove
>>>>> Cc: chris.keller@active-endpoints.com; wsbpel@lists.oasis-open.org
>>>>> Subject: Re: Fw: [wsbpel] Issue - 157 - conf call brief recap ... 
>>>>> and carry
>>>>> forward ...
>>>>>
>>>>> Hi guys,
>>>>>
>>>>> I wanted to just point out that the element-to-element node copy 
>>>>> (with name) is *not* only a substitution group problem:
>>>>>
>>>>> It also occurs in the case that something is uses xsd:choice or 
>>>>> xsd:any, which are not so uncommon.
>>>>>
>>>>> Rania
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>>> generates this mail.  You may a link to this group and all your 
>>>>> TCs in OASIS
>>>>> at:
>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>>> generates this mail.  You may a link to this group and all your 
>>>>> TCs in OASIS
>>>>> at:
>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>>>>
>>>>>
>>>>>  
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>> generates this mail.  You may a link to this group and all your TCs 
>>>> in OASIS
>>>> at:
>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  You may a link to this group and all your TCs 
>>> in OASIS
>>> at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>
>>
>>
>>
>>
>>
>>
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]