OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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
	- It must evaluate to exactly one node like the query
	- It must not be in an abstract process (same rationale as

Then we introduce new XPath functions which are mandatory for BPEL
	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.


- 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


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
don't say that we do), then we absolutely need something like XUpdate,
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
need an XUpdate analog, since simple updates are far too heavyweight in

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


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.

Message text written by INTERNET:ygoland@bea.com
Actually Chris nailed the missing feature for the XSLT proposal, the
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
For example XSLT(foo, bar) = bar. In other words, bar is both an input
an output of the transform.

In any case I think there are two separate issues here. One issue is -
need support for transforms. This is true regardless of any work we do
XUPDATE. I will file the issue with Peter.

The second issue is - what is the best programming model to solve the
problem? Clearly something like XUPDATE is going to be a lot easier to
with than XSLT. But I'm concerned that there is no way we can finish a
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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]