[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 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]