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

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

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).  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

-----Original Message-----
From: Danny van der Rijn [mailto:dannyv@tibco.com] 
Sent: Thursday, September 04, 2003 12:57 PM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 11 - Let's get a proposal nailed down

chris -

responses inline.

From: "Chris Keller" <chris.keller@active-endpoints.com>
> Danny,
>
> I have some questions on your proposal, which I'll try to pose within
> the context of a couple of examples.

>
> Example 1:
>
> <insertBefore>
> <from expression="'hello'"/>
> <to select="/foo/blah">
> </insertBefore>
>
> Would this create a sibling text node before blah?

yes.

>
> What message or part are we dealing with?  Should that be documented
the
> same as in a copy/to, but we are replacing query with select?
>

yes.  exactly.  leaving the attribute name as 'query' is ok with me,
too.
no strong opinion.

>
> Example 2:
>
> <insertBefore>
> <from message="poMessage" part="poHeader"
> query="/poHeader/poNumber"/>
> <to select="/foo/blah">
> </insertBefore>
>
> Would this create a sibling element named poNumber before blah, which
is
> a copy of the poNumber element (attributes and children) in the new
> tree?
>

i am a bit unclear, actually, on what copy will do in this situation -
i'd
like insertBefore to behave as close to copy as possible, for
consistency
reasons.  do you know what copy should do here?  in other words, will
blah
be replaced with copy of poNumber?  or will blah's children be replaced
with
poNumber's children?

> I think some of the other operations have the same issues/questions.
So
> answering these will probably do the same for them.
>
> Chris
>
> -----Original Message-----
> From: Danny van der Rijn [mailto:dannyv@tibco.com]
> Sent: Wednesday, September 03, 2003 2:15 PM
> To: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Issue - 11 - Let's get a proposal nailed down
>
> In today's conference call, we limited the scope of issue 11 to
exclude
> adding any new external dependencies.  Previously, of the 2
outstanding
> proposals, I think the consensus was leaning more towards my proposal.
> I
> propose that anyone who cares to refine my original proposal, or take
> the
> discussion elsewhere please do so.  The goal is to have a strawman
> votable
> proposal on the table at the F2F and then go from there.  Here, for
your
> convenience, is a link to my original proposal.
>
> danny
>
> http://lists.oasis-open.org/archives/wsbpel/200308/msg00157.html
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster
of
> the OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
> oup.php.
>
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster
of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.
>
>



To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.