Please ignore a partial draft that accidently was sent to the list, due
to my clumsy fingers.
This version of the proposal is revised to reflect Chris Keller's new
parameter naming scheme, and Alex's ideas about "inclusive" language to
allow (but not require) support for run-time updates to style sheets.
Other than these two changes, the proposal is the same as was sent
yesterday, which is substantially the same as what was sent out last
week.
-Ron
Procedural:
The resolution of issue 48 (XML Transform Support), which
was closed without a specification change, is hereby rescinded.
Section 9.4: append the following:
The above copy mechanism, when combined with the default
XPath 1.0 expression language, cannot perform complex XML
transformations. To address this restriction in a portable fashion, a
WS-BPEL
processor MUST support the bpws:doXslTransform() XPath 1.0
extension function, as described in the following paragraphs.
Function signature: Object
bpws:doXslTransform(String, node-set, (String, Object)*)
where:
- The first parameter (an XPath String) provides a URI naming the
style sheet to be used by the WS-BPEL processor. This must take the
form of a string literal.1
- The second parameter (an XPath node set) provides the source
document for the transformation to be performed by the WS-BPEL
processor.
This set must contain a single EII (i.e. an element node in XPath 1.0
data
model); if it does not, the WS-BPEL
processor MUST throw a bpws:xsltInvalidSource fault.
The
single EII as
specified by this parameter MUST be treated as the single child of the
root node of the source tree for XSLT processing.
- The optional parameters that follow must appear in pairs, as
follows. (Use of these values is explained below.)
- Firstly an XPath String parameter, which provides the qname
of an XSLT parameter
- Secondly an XPath Object parameter, providing the value for
the named XSLT parameter
- The result of the function MUST provide the
result of the transformation. It will be one of the following infoset
items,
depending on the XSLT output method employed by the selected style
sheet:
- A single TII (an XPath 1.0 text node), created by the "text"
or "html" output methods, or
- A single EII (an XPath element node that is the single child
of the root of the result tree), which is created by the "xml" output
method.
The WS-BPEL processor MUST execute the bpws:doXslTransform
method
such that all of the following apply:
- The first parameter, naming the style sheet to be used, MUST be
used to find the style sheet corresponding to the given URI. This is
accomplished in an implementation-dependent fashion. If the style sheet
corresponding to the given URI cannot be found, the WS-BPEL processor
MUST
throw a bpws:xsltStylesheetNotFound fault.
- The processor MUST perform an XSLT 1.0 transformation, as
described in section 5.1 (Processing Model) of the XSLT 1.0
specification, using the named style sheet as primary sheet sheet, the
provided source EII as the source document, and the result tree as the
result of the transformation.
- Optionally, XSLT global parameters (section 11.4 of [XSLT 1.0])
are used to pass
additional values from the BPEL process to the XSLT processor. The
optional parameters for doXslTransform function are used to
identify the XSLT global parameters by qualified name, and to supply
values for the named global parameters, as described above. The WS-BPEL
processor MUST pass the given global parameter names and values to the
XSLT processor.
- Any XSLT processing faults that occur during the transformation
MUST
result in a bpws:subLanguageExecutionFault being thrown.
Note that because XSLT is a side effect-free language, execution of the
transformation cannot (by definition) cause any changes to BPEL
variables referred to in the style sheet.
1 The purpose of this restriction is to allow
implementations to statically analyse the process (and named style
sheets) for variable dependencies. Style sheets associated with a
process (through its doXslTransform invocations) are
considered part of the process definition, and in most situations would
not change at run-time. However, WS-BPEL processors MAY dynamically
update associated style sheets at run-time, as long as all requirements
of this specification are still met (in particular, the semantics of
"atomic" assignment and serialized scopes).
Section A (Standard Faults): add the following faults to the table:
| Fault Name |
Reason |
| xsltStylesheetNotFound |
The named style sheet in a bpws:doXslTransform
function call was not found
|
| xsltInvalidSource |
The transformation source provided in a bpws:doXslTransform
function call was not legal (i.e., not an EII).
|
bpws:doXslTransform Example
Complex document transformation. A common pattern
in BPEL processes involves a sequence of receiving an XML document from
one service, converting it to a different schema to form a new request
message, and sending the new request to another service. Such
documentation conversion is easier accomplished using XSLT, using the
doXslTransform function For example:
<variables>
<variable name="A" type="foo:AType"/>
<variable name="B" type="bar:BType"/>
</variables>
...
<sequence>
<invoke ... inputVariable="..." outputVariable="A"/>
<assign>
<from>
<expression>
bpws:doXslTransform("urn:stylesheets:A2B.xsl", $A)
</expression>
</from>
<to variable="B"/>
</assign>
<invoke ... inputVariable="B".../>
</sequence>
In the sequence, a service is invoked, and the result (of type
foo:AType) copied to variable A. The assign activity is used to
transform the contents of variable A to type bar:BType, and copy the
result of that transformation to variable B. Variable B is used to
invoke another service.
The style sheet A2B.xsl would contain the XSL rules for converting
documents of schema foo:AType to schema bar:BType.
Iterative document construction and BPEL variable access.
Suppose that we are
constructing a document by repeatedly calling a service, and
accumulating the result in an XML variable. The loop might look
something like this:
<variables>
<variable name="PO" type="foo:POType"/>
<variable name="OutVar" type="foo:ItemType"/>
</variables>
<!-- ... PO is initialized ... -->
<!-- Iteratively add more items to PO until complete -->
<while>
<condition>...not done...</condition>
<sequence>
<!-- Fetch next chunk into OutVar -->
<invoke ... inputVariable="..." outputVariable="OutVar"/>
<assign>
<from>
<expression>
bpws:doXslTransform("urn:stylesheets:AddToPO.xsl", $PO,
"NewItem", $OutVar)
</expression>
</from>
<to variable="PO"/>
</assign>
</sequence>
</while>
The optional parameters given in the doXslTransform call
specify that the XSLT parameter named "NewItem" must be set
with the value of the BPEL variable OutVar. To allow the XSLT
style sheet access to this value, it must contain a global (top-level)
parameter
with a name matching that given in the third parameter of the function
call shown above.
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<!-- NewItem variable set by BPEL process; defaults to empty
item
-->
<xsl:param name =
"NewItem"><item/></xsl:param>
...
</xsl:transform>
The style sheet would contain a template similar to the following,
responsible for appending the value of global parameter NewItem
(the value of OutVar from the process instance)to
the
existing list of items in the PO variable.
<xsl:template match="item"> <!--
line 1 -->
<xsl:copy-of select="."/> <!-- line 2
-->
<xsl:if test="position()=last()"> <!--
line 3 -->
<xsl:copy-of select="$NewItem"/> <!--
line 4 -->
</xsl:if> <!--
line 5 -->
</xsl:template> <!--
line 6 -->
This template copies all existing items in the source document
(lines 1 & 2), and appends the contents of the XSLT parameter NewItem
to the
list of items (line 3 tests to see if the current node is at the end of
the item list; line 4 copies the result-tree fragment from the XSLT
parameter NewItem to follow the the last item. Thus, if PO
has
a value of:
<po><item>item 1</item></po>
at the beginning of an iteration of the the above loop, and the <invoke>
activity returns a value of <item>FooBar</item>,
evaluation of the <from> expression will result in a
value of:
<po><item>item
1</item><item>FooBar</item></po>
which, when the BPEL copy activity is complete, will become
the new value of the PO variable.
|