Re: [wsbpel] Draft: Issue - 11 - Discussion & Proposals

[Rania Khalaf <rkhalaf@watson.ibm.com>]

When we did 157, xslt was proposed and a lot of people - or maybe a few 
very vocal people (i can't recall who right now) - were very much 
against xslt since it 'would introduce lots of unknowns and we don't 
have time to debug this now' or something like that.

so my point is, that if we go the xslt way here, that affects 157 as 
well and the arguments against xslt should be discussed.

i personally like chris's proposal and especially if uses the infoset 
language as yaron had suggested.

my .02, r

Ron Ten-Hove wrote:
> I would like to amend Ugo Corda's proposal for issue 11 
> <http://www.oasis-open.org/apps/org/workgroup/wsbpel/email/archives/200503/msg00231.html>, 
> currently before the TC, by replacing it with following proposal 
> (omitting the section on motivation).
> 
> This actually proposes three variants on the same basic solution. I 
> propose that we first vote on the basic approach, and if it is 
> acceptable to the TC, then we can vote on which particular variant (or 
> variants) should be used.
> 
> Note: this is best viewed using an HTML-enabled mail reader.
> 
> 
>       Motivation
> 
>     BPEL4WS 1.1 has one glaring flaw, that most users run across rather
>     quickly: the weakness of the <assign> mechanism. Virtually every
>     user recognizes that the <assign> <copy> mechanism is too limited to
>     perform real tasks at all, and is painful to use to perform those
>     limited tasks to which it is suited. BPEL engine vendors,
>     recognizing the same problem, have been forced to supply proprietary
>     extensions to address this deficiency. Put succinctly, BPEL cannot
>     handle complex XML assignment in a portable way.
> 
>     WS-BPEL 2.0 has yet to significantly address this issue, despite
>     over two years of development by the BPEL TC. It would be a
>     significant, highly visible failure if we were to do nothing to
>     properly address this problem.
> 
>     Unraveling the assignment problem is not a matter of invention;
>     other open standards have addressed the problem of XML manipulation
>     and composition, and new standards are improving on existing ones. A
>     solution to this problem is as simple as embracing an appropriate
>     standard.
>     //
> 
>         /Why not leave this to vendors to solve, as they have with
>         BPEL4WS 1.1? /In a word, portability. XML data manipulation is
>         an important technical aspect of BPEL processes. Yet it is
>         impossible to create a portable process for all but the most
>         simplistic processes.
> 
>         Put another way, we make portability of expressions possible by
>         requiring XPath 1.0 support. Why can't we do something similar
>         for complex assignment?
> 
>     Note that solving the portability problem doesn't require the
>     creation of a general solution that is applicable to all possible
>     expression languages. It is sufficient to build on the XPath 1.0,
>     which must be used exclusively if a portable process is to be
>     defined by the user.
> 
> 
>       The Basic Idea
> 
>     The <assign> activity is extensible in two ways, which allows
>     vendors to supply proprietary extensions that work around the limits
>     of <assign>. The two extension mechanisms are:
> 
>         * XPath extension functions, which can be used in
>           assign/copy/from elements.
>         * Non-BPEL name space elements inside an assign/extensibleAssign
>           element.
> 
>     Regardless of the type of extension used, the basic idea behind the
>     proposal is the same: a standard, BPEL-defined function or element
>     that supports XSLT 1.0 transformation.
> 
>         /Why XSLT 1.0? /Put simply, it is the best technology available
>         to do that job that is standardized today. Other standards are
>         in the works that will improve on it, but we cannot take a
>         dependency on an unstable standard.
> 
>     This proposal outlines three variants of this basic idea:
> 
>             * An XPath extension function.
>             * A extensible-assign extension element that is XSLT
>               1.0-specific
>             * A extensible-assign extension element that parameterizes
>               the transformation type; XSLT 1.0 support is required.
> 
>     Only one variant is required to solve issue 11; which one (or ones)
>     we should adopt is a matter of taste. In the interest of not
>     imposing one group's particular tastes on the TC, the following
>     subsections discuss each variant in turn.
> 
> 
>             XPath Extension Function
> 
>         This simplest way to express this idea is using an XPath
>         extension function:
> 
>             <assign>
>               <copy>
>                 <from>*bpws:doXslTransform('a-to-b.xsl', $invar)*</from>
>                 <to variable="outvar"/>
>               </copy>
>             </assign>
> 
>         A compliant BPEL implementation MUST support the XPath 1.0
>         extension function, bpws:DoXslTransform, which  is used to
>         perform XML-to-XML transformation tasks using XSLT 1.0
>         <http://www.w3.org/TR/xslt.html>. It is defined as:
> 
>             *Function*: /node-set/ bpws:doXsltTransform(/String/,
>             /node-set/)
> 
>         where:
> 
>             * The first argument, of type /String/, is used to name the
>               XSLT style sheet to be used for the transformation. This
>               is used by implementations to locate the style sheet in an
>               implementation-determined manner.
>             * The second argument, of type /node-set/, is the source
>               document to be transformed. This must refer to an in-scope
>               variable of an XML type.
>             * The returned value, of type /node-set/, is the result of
>               the transformation.
>             * If an XSLT processing error occurs during transformation,
>               a TBD fault MUST be thrown.
> 
>         A BPEL processor MUST evaluate the doXsltTransform function by
>         performing standard XSLT 1.0 processing
>         <http://www.w3.org/TR/xslt.html#section-Processing-Model>, using
>         the style sheet named by the first parameter as the primary
>         style sheet, the node set indicated by the second parameter as
>         the source document, and the result-tree of the transformation
>         as the result of the function.
> 
>         The XSLT processor invoked by this extension function MUST make
>         the bpws:GetVariableProperty() function available, as an
>         extension function. This will permit style sheets to access
>         in-scope variable values.
> 
> 
>             XSLT Transformation <assign> Extension Element
> 
>         Alternatively, we can use the extension mechanism defined by the
>         resolution to issue 11.1. This could take the form illustrated
>         below:
> 
>             <assign *xmlns:bpwsext =
>             "http://schemas.xmlsoap.org/ws/2004/03/business-process/extensions/"*>
>               <extensibleAssign>
>             *    <bpwsext:transform style sheet="a-to-b.xsl"
>                                source="invar" result="outvar"/>
>             *  </extensibleAssign>
>             </assign>
> 
>         the bpwsext:transform element describes an XSL transformation
>         similar to the one detailed above, using an XPath extension. The
>         XML takes the form:
> 
>             <transform style sheet="xsd:string" source="ncname"
>             result="ncname"/>
> 
>         where the attributes are used as follows:
> 
>             * *style sheet*. This indicates the name of the XSLT style
>               sheet to be used for the transformation. This is used by
>               implementations to locate the style sheet in an
>               implementation-determined manner.
>             * *source*. This names the XML variable (in the current
>               scope) that serves as the source document for the
>               transformation.
>             * *result*. This names the XML variable (in the current
>               scope) that will be assigned the result of the transformation.
> 
>         A BPEL processor MUST evaluate the <ext:transform> element at
>         run-time by performing standard XSLT 1.0 processing
>         <http://www.w3.org/TR/xslt.html#section-Processing-Model>, using
>         the style sheet named as the primary style sheet, the node set
>         indicated by the source attribute as the source document, and
>         the result-tree of the transformation must be copied to the
>         variable named by the result attribute. If an XSLT processing
>         error occurs during transformation, a TBD fault MUST be thrown,
>         and the value of the result variable MUST NOT be changed.
> 
>         The XSLT processor invoked by this extension element MUST make
>         the bpws:GetVariableProperty() function available, as an
>         extension function. This will permit style sheets to access
>         in-scope variable values.
> 
> 
>             Generalized Transform <assign> Extension Element
> 
>         We can generalize the above transformation extension element, by
>         adding a transformation type indicator:
> 
>             <assign xmlns:bpwsext =
>             "http://schemas.xmlsoap.org/ws/2004/03/business-process/extensions/*"*>
>               <extensibleAssign>
>                 <ext:transform
>             *type="**|http://www.w3.org/1999/XSL/Transform|**"*
>                                source="invar" result="outvar">
>                   a-to-b.xsl
>                 <ext:transform/>
>               <extensibleAssign>
>             </assign>
> 
>         using type to indicate, by URI, the transformation type (XSLT
>         1.0 in this case), and supplying any type-specific data inside
>         the <bpwsext:transform>.
> 
>         Implementations must support XSLT 1.0 as shown above, and as
>         described in the previous section.
> 
>