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