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

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

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