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

[David RR Webber - XML ebusiness <Gnosis_@compuserve.com>]

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