I would like to amend Ugo
Corda's proposal for issue 11, 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. 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, 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,
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.
|