RE: [wsbpel] Issue - 11 - Proposal to vote

["Satish Thatte" <satisht@microsoft.com>]

Understood.  So long as it is nicely encapsulated as a simple feature
leveraging the XPath work I have no objection to it.

-----Original Message-----
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] 
Sent: Monday, October 24, 2005 9:31 AM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 11 - Proposal to vote

Satish,

    The current proposal doesn't affect the extension mechanisms already
available to vendors to add other transformation technologies. Vendors
will still have to think out how the data models between the BPEL
universe and the transformation universe intersect. If a vendor were
contemplating adding support for a transformation language that used
XPath 1.0's data model, he might look use the doXslTransform() extension
function as a guide.

    With Chris's latest change to the proposal, we have a very clean,
one-way transition between the BPEL and XSLT worlds. In particular it
leverages all of our hard work nailing down the semantics of issue 103
(and its friends & relations), leaving us with a very clean hand-off
between BPEL's XPath 1.0 view of its data model and the XSLT 1.0
mechanism for communicating "parameters" from the world outside the XSLT
engine. This leaves us with the relatively simple job of describing a
straightforward XPath 1.0 extension function. Issue 103 and XSLT 1.0 do
the heavy lifting for us.

-Ron

Satish Thatte wrote:

>I admit I haven't followed the recent detailed discussion of 11.  I do
>agree with Dieter point that XSLT is desirable relative to peculiar
BPEL
>data manipulation features and also that a 103-like protracted effort
>for semantic naildown is not desirable.  I would like to hear the
>opinion of the currently active participants in the 11 discussion on
how
>close we are and much effort it would take to make this XSLT feature a
>foolproof addition to BPEL with the door open for other transformation
>models using infoset terminology, etc.
>