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
|