Re: [wsbpel] Issue - 11 - Ambiguous insertion points

[Danny van der Rijn <dannyv@tibco.com>]

darn it.  hit 'send' prematurely.

objection #5: *if* we decide to support remove and/or rename, this syntax
won't support them.  (no "from" in remove, and reusing "from" in rename
would be awkward).

danny
----- Original Message ----- 
From: "Danny van der Rijn" <dannyv@tibco.com>
To: <wsbpel@lists.oasis-open.org>
Sent: Wednesday, August 13, 2003 12:10 PM
Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points


> ahh.  i got confused by the 'bar' in the to expression from before.
>
> > <copy>
> >     <from .../>
> >     <to expression="bpws:insertVariableNode('variable', 'part',
> >                                             'bar','/foo', 'blah')/>
> > </copy>
>
> in your latest clarification it goes to the <from> element if i'm not
> mistaken.
>
> so now we're down to the nitty gritty details.  thank goodness ;-)  i'm
> perfectly happy with the overall format of your suggestion.  however, i
have
> some objections to parts of it.
>
> objection #1: i don't like the idea of a function creating a node that is
> about to be changed by the <copy> element.  that's extra overhead.
>
> objection #2: you still don't differentiate between inserting before and
> after.  when operating on yaron's now canonical
>
> <foo>
>    <blah/>
> </foo>
>
> and the function is
> <copy>
>   <from expression="'blah'"/>
>   <to expression="bpws:insertVariableNode('variable', 'part', '/foo/bar,
> '/foo', /foo/blah')/>
>  </copy>
>
> do you get
> <foo>
>   <bar>
>   <blah>
> </foo>
> (insert before)
>
> or
>
> <foo>
>   <blah>
>   <bar>
> </foo>
> (insert after)
>
> just to be clear, my proposed append operation would yield
> <foo>
>   <blah>
>     <bar/>
>   </blah>
> </foo>
> with the optional parameter determining between which siblings bar would
get
> placed.  in this case, there were no siblings, so the parameter was moot.
>
>
> objection #3: i'm not thrilled with the overloading (optional parameter
> changes function from append to insert).
>
>
> objection #4: might not be an objection, but it looks to me like some of
the
> parameters are redundant.
>
> feeling like a lot of progress is being made (even if it's just the 2 of
us
> reading...)
> danny
>
> ----- Original Message ----- 
> From: "Chris Keller" <chris.keller@active-endpoints.com>
> To: "'Danny van der Rijn'" <dannyv@tibco.com>;
<wsbpel@lists.oasis-open.org>
> Sent: Wednesday, August 13, 2003 11:39 AM
> Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
>
>
> > Understood, the xupdate usage was functionality not syntax.  Thanks for
> > clarifying.  In that case I think we are in heated agreement.  We only
> > deviate in the style in which it should be implemented.  In the style of
> > copy I suggested the <from> contains the data to be copied to the newly
> > created node which the function created and placed (as dictated by the
> > parameters) in the XML fragment.  Here is a proposed syntax for your use
> > cases.
> >
> > Case 1:
> > <insertBefore>
> >   <from/>
> >   <to select="XPath Expression evaluates to one node"/>
> > </insertBefore>
> > creates a sibling before the select expression
> >
> > becomes:
> > <copy>
> >   <from/>
> >   <to expression="bpws:insertVariableNode('variable', 'part', 'qname of
> > new element, 'parentPath part of your xpath expression evaluates to one
> > node', 'path of sibling to insert before evaluate to one node')/>
> > </copy>
> >
> > The reason for splitting the parent and sibling paths in my function is
> > that the sibling path is optional, which is a reasonable use case.
> >
> > Case 2
> > <insertAfter>
> >   <from/>
> >   <to select="XPath Expression evaluates to one node"/>
> > </insertAfter>
> > creates a sibling after the select expression
> >
> > Becomes:
> > <copy>
> >   <from/>
> >   <to expression="bpws:appendVariableNode('variable', 'part', 'qname of
> > new element, 'parentPath part of your xpath expression evaluates to one
> > node', 'path of sibling to append after evaluates to one node')/>
> > </copy>
> >
> > Case 3:
> > <append>
> >   <from/>
> >   <to select="XPath Expression evaluates to one node" child="integer
> > XPath
> > expression"? />
> > <append>
> > creates a child of select expression at the child-th position.  child
> > defaults to last().
> >
> > Becomes:
> > <copy>
> >   <from/>
> >   <to expression="bpws:appendVariableNode('variable', 'part', 'qname of
> > new element, 'parentPath xpath expression evaluates to one node')/>
> > </copy>
> > Just remove optional sibling path and it defaults to last().
> >
> > Case 4:
> > <remove select="XPath expression evaluates to one node">
> > removes a node
> >
> > Becomes:
> > Sorry didn't introduce a remove, but I agree this could have some value.
> >
> > Case 5:
> > <rename select="XPath expression evaluates to one node"
> > newName="ncname"/>
> > for completeness, don't have strong feelings about its inclusion
> >
> > Becomes:
> > Sorry didn't introduce a rename.
> >
> >
> >
> > I hope this helps clarify the proposal.
> >
> > Chris
> >
> >
> > -----Original Message-----
> > From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > Sent: Wednesday, August 13, 2003 2:10 PM
> > To: wsbpel@lists.oasis-open.org
> > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points
> >
> > > The main reason for the XPath route was in response to Yaron's comment
> > > on finishing the standard on time.  And this seemed like an acceptable
> > > compromise since it deviates very little from the current
> > specification.
> > > Introducing the xupdate syntax seemed like a bigger nut to crack and
> > it
> > > also introduces a dependency on another specification, which people
> > > would need to digest.
> >
> > i'm not suggesting a dependency on XUpdate, just the concepts from it,
> > which
> > we're already bandying around.  i'm simply using XUpdate as shorthand
> > for
> > the functionality that we're talking about, in whatever syntactic form
> > it
> > comes in.
> >
> > > <copy>
> > >     <from .../>
> > >     <to expression="bpws:insertVariableNode('variable', 'part',
> > >                                             'bar','/foo', 'blah')/>
> > > </copy>
> >
> > so what's the point of the <from> clause here?
> >
> > i'm not sure why changing BPEL syntax is different from adding XPath
> > functions, but i realize that i haven't been too explicit either.  what
> > i'm
> > looking at is the following possible elements under <assign>:
> >
> > <copy>
> >   <from/>
> >   <to/>
> > </copy>
> > as current.
> >
> > <insertBefore>
> >   <from/>
> >   <to select="XPath Expression evaluates to one node"/>
> > </insertBefore>
> > creates a sibling before the select expression
> >
> > <insertAfter>
> >   <from/>
> >   <to select="XPath Expression evaluates to one node"/>
> > </insertAfter>
> > creates a sibling after the select expression
> >
> > <append>
> >   <from/>
> >   <to select="XPath Expression evaluates to one node" child="integer
> > XPath
> > expression"? />
> > <append>
> > creates a child of select expression at the child-th position.  child
> > defaults to last().
> >
> > <remove select="XPath expression evaluates to one node">
> > removes a node
> >
> > <rename select="XPath expression evaluates to one node"
> > newName="ncname"/>
> > for completeness, don't have strong feelings about its inclusion
> >
> > end result: nice clean syntax; nothing too major added; hopefully
> > doesn't
> > require a lot more work, spec can go forward.
> >
> > ----- Original Message ----- 
> > From: "Chris Keller" <chris.keller@active-endpoints.com>
> > To: "'Danny van der Rijn'" <dannyv@tibco.com>;
> > <wsbpel@lists.oasis-open.org>
> > Sent: Wednesday, August 13, 2003 10:37 AM
> > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
> >
> >
> > > Danny -
> > >
> > > Sorry, I should have been more explicit with the example.  Let's take
> > > the case Yaron had brought up of /foo/blah and we would like to insert
> > > bar as a child of foo before blah.
> > >
> > > So before the copy the document fragment looks like:
> > > <foo>
> > >   <blah/>
> > > </foo>
> > >
> > > We execute the following copy:
> > >
> > > <copy>
> > >     <from .../>
> > >     <to expression="bpws:insertVariableNode('variable', 'part',
> > >                                             'bar','/foo', 'blah')/>
> > > </copy>
> > >
> > > The result would be:
> > >
> > > <foo>
> > >   <bar>...</bar>
> > >   <blah/>
> > > </foo>
> > >
> > > If instead we had executed the following copy:
> > >
> > > <copy>
> > >     <from .../>
> > >     <to expression="bpws:appendVariableNode('variable', 'part',
> > >                                             'bar','/foo', 'blah')/>
> > > </copy>
> > >
> > > The result would be:
> > >
> > > <foo>
> > >   <blah/>
> > >   <bar>...</bar>
> > > </foo>
> > >
> > > The "append" versus "insert" would be used to decide whether you are
> > > appending the new child or inserting the new child.  If the sibling
> > name
> > > is not specified then this results in putting the new child at the end
> > > of the list or beginning of the list of children respectively.
> > >
> > > I don't know if we need more than these two for positioning, but I
> > could
> > > be wrong.  If we want rename and remove functionality (although rename
> > > is less of an issue it is hard to make a case for when that is needed)
> > > we could do that by adding the functions that you mentioned.  Also I
> > > think we can leave the <copy><to...> as an update and let the
> > functions
> > > handle the node creation and return of the new single node list.
> > >
> > > The main reason for the XPath route was in response to Yaron's comment
> > > on finishing the standard on time.  And this seemed like an acceptable
> > > compromise since it deviates very little from the current
> > specification.
> > > Introducing the xupdate syntax seemed like a bigger nut to crack and
> > it
> > > also introduces a dependency on another specification, which people
> > > would need to digest.
> > >
> > > Chris
> > >
> > > -----Original Message-----
> > > From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > > Sent: Wednesday, August 13, 2003 1:07 PM
> > > To: wsbpel@lists.oasis-open.org
> > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points
> > >
> > > chris -
> > >
> > > i'm not sure i see how the new functions would be used.  could you
> > give
> > > an
> > > example?  also, the insertVariableNode is ambiguous, as yaron has
> > > pointed
> > > out - you'd need an insertVariableNodeBefore, and an
> > > insertVariableNodeAfter.
> > >
> > > after you do that, you could include a removeVariableNode and a
> > > renameVariableNode.  if you do that, you've got all the functionality
> > of
> > > my
> > > previous suggestion.
> > >
> > > i don't have particularly strong feelings about the syntax for the
> > > provided
> > > functionality, although i have a mild bias against XPath functions.
> > >
> > > one thing i would like to do, however, is reconcile whatever syntax we
> > > come
> > > up with with the <copy><to> syntax, as it's really just an
> > > updateVariableNode XPath function, and i think that it would be ugly
> > to
> > > have
> > > different syntax for update than the others.
> > >
> > > danny
> > >
> > > ----- Original Message ----- 
> > > From: "Chris Keller" <chris.keller@active-endpoints.com>
> > > To: <wsbpel@lists.oasis-open.org>
> > > Cc: "'Danny van der Rijn'" <dannyv@tibco.com>; <ygoland@bea.com>;
> > > <Gnosis_@compuserve.com>
> > > Sent: Wednesday, August 13, 2003 6:34 AM
> > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
> > >
> > >
> > > > Here is another idea for solving this issue.
> > > >
> > > > Allow the <to> element to contain an expression with the following
> > > > restrictions.
> > > > - It must evaluate to exactly one node like the query
> > > > restriction.
> > > > - It must not be in an abstract process (same rationale as
> > > > query).
> > > >
> > > > Then we introduce new XPath functions which are mandatory for BPEL
> > > > implementations.
> > > > bpws:appendVariableNode('variable', 'part', 'childQname',
> > > > 'parentPath'[, 'siblingQname'])
> > > > bpws:insertVariableNode('variable', 'part', 'childQname',
> > > > 'parentPath'[, 'siblingQname'])
> > > >
> > > > These methods could be used to create specific children at the right
> > > > levels.  We may need to have a few more functions.  But anyone
> > > > implementing a BPEL engine must already make new functions available
> > > to
> > > > the XPath processor.  And this seems like the least deviation from
> > the
> > > > current specification and allows some great flexibility.  Although
> > we
> > > > may need a few more functions (TBD).
> > > >
> > > > The user could theoretically use the current copy <to
> > variable='...'>
> > > > for example:
> > > > <to variable='varname' part='partname' query='querypath'/>
> > > >
> > > > Or an equivalent:
> > > > <to expression="bpws:getVariableData('varname', 'part',
> > > 'querypath')"/>
> > > >
> > > > This particular case is a little redundant, but we have that
> > somewhat
> > > > already with literal and expression, since an expression can be just
> > a
> > > > quoted string.
> > > >
> > > > Thoughts?
> > > >
> > > > - Chris
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > > > Sent: Tuesday, August 12, 2003 2:05 PM
> > > > To: wsbpel@lists.oasis-open.org
> > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points
> > > >
> > > > david-
> > > >
> > > > without allowing XSLT multiple inputs, you have the choice of either
> > > > creating some new data, or rebuilding some variable based only on
> > > > itself.  i
> > > > submit that if we don't want to deal with multiple inputs for XSLT
> > > (and
> > > > i
> > > > don't say that we do), then we absolutely need something like
> > XUpdate,
> > > > since
> > > > the current spec doesn't have enough data manipulation capabilities.
> > > >
> > > > even if we do want to deal with XSLT with multiple inputs, i still
> > > think
> > > > we
> > > > need an XUpdate analog, since simple updates are far too heavyweight
> > > in
> > > > XSLT.
> > > >
> > > > i'm interested to know if satish thinks the ocean is getting warm
> > ;-)
> > > >
> > > > ----- Original Message ----- 
> > > > From: "David RR Webber - XML ebusiness" <Gnosis_@compuserve.com>
> > > > To: <ygoland@bea.com>
> > > > Cc: <wsbpel@lists.oasis-open.org>
> > > > Sent: Monday, August 11, 2003 6:55 PM
> > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
> > > >
> > > >
> > > > Yaron,
> > > >
> > > > I'm glad you are filing this issue.
> > > >
> > > > Once you cross-over into the territory of multiple inputs,
> > > > and merging, sorting, filtering - you get beyond XSLT and
> > > > into the land of traditional data mappers.
> > > >
> > > > Why are you thinking the W3C will care about this?!?
> > > >
> > > > My 0.2cents on this - take a linear approach -
> > > >
> > > > 1) Simple transactions - a la current spec'.
> > > >
> > > > 2) More complex needs - but still relatively light - XSLT
> > > >
> > > > 3) Heavy lifting - provide a call-out mechanism and let
> > > >      people choose their own toolset.
> > > >
> > > > Implementers needing this will agree amongst themselves
> > > > on what to use - we certainly do not need to start re-inventing
> > > > wheels here within BPEL - we've enough other work to
> > > > look at.
> > > >
> > > > Pass the baton - and move on.
> > > >
> > > > DW.
> > > > ==================================================
> > > > Message text written by INTERNET:ygoland@bea.com
> > > > >
> > > > Actually Chris nailed the missing feature for the XSLT proposal, the
> > > > ability
> > > > to submit multiple inputs. Once one can specify multiple input
> > > documents
> > > > into the transform then there is no limit to what the output can
> > look
> > > > like.
> > > > For example XSLT(foo, bar) = bar. In other words, bar is both an
> > input
> > > > and
> > > > an output of the transform.
> > > >
> > > > In any case I think there are two separate issues here. One issue is
> > -
> > > > we
> > > > need support for transforms. This is true regardless of any work we
> > do
> > > > with
> > > > XUPDATE. I will file the issue with Peter.
> > > >
> > > > The second issue is - what is the best programming model to solve
> > the
> > > > insert
> > > > problem? Clearly something like XUPDATE is going to be a lot easier
> > to
> > > > deal
> > > > with than XSLT. But I'm concerned that there is no way we can finish
> > a
> > > > fully
> > > > spec'd XUPDATE standard in time and it isn't even clear that this is
> > > > something the BPEL TC should work on. XUPDATE sounds like a job for
> > > the
> > > > W3C.
> > > > <
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> > > > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> > > >
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> > > > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>