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


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

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

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