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 ...


huh ? i don't think we have opposite names for source and target!

I'm saying that the attribute should clarify direction. In your email 
you say you want to keep the name of the element in the from, hence, 
retainSourceElementName ..


I think there's a misunderstanding here.

r

Alex Yiu wrote:
> 
> Hi Rania,
> 
> Hmmm ... from my view point: "source" is pointed by from-spec ... 
> "target" is pointed by the to-spec. [ I guess somehow you use the 
> flipped version of terms compared with mine ... ;-) ]
> 
> Again, think of an assignment statement in a procedural language will 
> help us clear up and standardize our terms.
> 
> target:= source.
> (i.e. assign from "source" to "target")
> 
> "replace" or "retain" - one way or the other .... I don't have a strong 
> opinion as of this moment. About "source" vs "target", <copy> is always 
> about changes in the "target" element (if the above version of terms are 
> adopted).
> 
> Make senses ?
> 
> Thanks!
> 
> Regards,
> Alex Yiu
> 
> 
> 
> Rania Khalaf wrote:
> 
>> 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 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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]