Hi Ron,
I think it is a good idea to revisit this type
of proposal, which has been tossed around quite a bit under issue 11 and also
under issue 48 which was opened and then closed. Here are some of my initial comments.
Option 1:
1 – Should parameter 1 be a string which
must be a URI?
2 – For parameter 2 we should clarify
what is meant by node-set, is it a node-set with exactly one node in it. In
the text it is described as a source document, what if it is an element or an
attribute or some other type of node?
3 - Besides access to the
getVariableProperty function, we should also specify access to all $var
variables (as described in issue 103).
4 – For extensibility why not have an
optional third parameter indicating the transformation language like option 3.
Options 2 & 3:
1 – If we adopt either of these why
would we use the extensible syntax?
2 – These seem more limited than
option 1, given all the work we did for issue 157 to make copy better. In
other words I can’t copy the result of a transform into a child node of a
variable.
General note:
Some examples would be nice. In particular
one issue with the current assign/copy is dealing with an incremental build of
a variable. One very important build-up is the result set of a parallel
forEach. Could you provide an example using any of the options for this
use case?
- Chris
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Tuesday, October 04, 2005
8:15 PM
To: wsbpeltc
Subject: [wsbpel] Draft: Issue -
11 - Discussion & Proposals
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.