RE: [wsbpel] Issue - 11 - Let's get a proposal nailed down

["Chris Keller" <chris.keller@active-endpoints.com>]

+1
-----Original Message-----
From: Monica Martin [mailto:monica.martin@sun.com] 
Sent: Friday, September 05, 2003 9:54 AM
To: chris.keller@active-endpoints.com
Cc: 'Danny van der Rijn'; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 11 - Let's get a proposal nailed down

Chris Keller wrote:

>Danny,
>
>The way the current copy/to functionality reads is as a content
>replacement not a node copy.  Although it is not clear the treatment of
>attributes and child nodes for query (since there are no examples), but
>based on the requirement that the types be compatible it would appear
to
>be a complete content copy (attributes and child nodes).  
>
mm1: As we have seen with issue 52, perhaps we need a few examples or 
even use cases to solidify what the requirements are here - content 
replacement
or node copy.

>This is a
>little different then the insertBefore behavior you have described in
>that you would also be copying the main node.  We may want to specify a
>QName for the child to create if we want the same behavior.  
>
>The introduction of a child QName could also solve another issue I am
>thinking about with your proposed syntax. That question is how one
would
>build up complex content.  So if one wants to build a
>PO/Header/ShippingAddress and you are starting with a blank part what
>would be the correct syntax.  It looks like I can do a raw data move
>from a literal to the part as a blank template, which I don't
>particularly like the idea of, or I am out of luck if I don't have a
>source element QName matching my target. So giving a child QName to
>create would at least allow you to build up the complex type by a
series
>of blank inserts or appends.  If we don't want the series of blank
>appends the child QName could be replaced with a Path, but we would
have
>to have some caveats on what is allowable for that type of path.  In
any
>case I think this requires more thought. My XPath function approach had
>a little of this described you may want to take a look at it.
>
>Chris
>  
>