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

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

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