[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 ...
... ;-) ... as mentioned in the conf call 2 days ago, it was just ... we were looking at the same data / operation from different directions. It would be fine, as long as the majority of people agree on a clear terminology. :-) Regards, Alex Yiu Rania Khalaf wrote: > 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]