Re: Fw: [wsbpel] Issue - 157 - conf call brief recap ... and carryforward ...

[Alex Yiu <alex.yiu@oracle.com>]

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