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

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

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