[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. <
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]