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