Hi,
This is looking very good! I just have a comment
regarding qname expansion:
XSLT explicitly states how it handles qname
expansion for its parameters (http://www.w3.org/TR/xslt#qname),
i.e. default namespace is not used when prefix is null.
Similarly, XPATH 1.0 says that the default
namespace should not be used for ‘node tests’, but it does not say
anything on how to interpret string literals of the type qname.
This is in contrast to W3C Schema
primitive type qname, which does rely on the default namespace (http://www.w3.org/TR/xmlschema-1/#src-qname)
for qname expansion.
Am I missing something, or should we be
explaining how to expand the doXslTransform qname parameter? I am assuming we
also don’t want it to use the default namespace, so that it maps seamlessly
to XSLT…
Rgds,
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Tuesday, October 25, 2005
1:59 PM
To: wsbpeltc
Subject: [wsbpel] Issue - 11 -
Proposed Resolution for 10/26 meeting
Gentle-beings,
This is the latest revision of the proposal, amending Ugo's
proposed resolution to issue 11 by replacing it with the spec language supplied
below.
This differs from last week's version in some minor ways:
- Key words such as MUST are capitalized
consistently, in conformance to RFC 2119.
- Section 9.3 (Expressions) contains a general
prohibition against non-string literal arguments in BPEL XPath functions.
This is now qualified, and the exception to this rule noted in the
description of doXslTransform.
- The doXslTransform
function parameters that supply the global parameter QNames are further
restricted:
- They must be a
string literal values, and
- They must conform
to the XML Namespaces definition of QName (i.e., use prefixes for the
namespace URI).
I suspect this final restriction
must be added to our definition of bpws:getVariableProperty's
second parameter (the property name). Unless someone points me to the part of
the spec that defines this for the property name parameter of getVariableProperty,
I'll open a new issue, with a proposed resolution using language similar to
that used for the global parameter QNames defined below.
-Ron
Procedural:
The resolution of issue 48 (XML Transform Support), which
was closed without a specification change, is hereby rescinded.
(It will be re-closed, this time with a resolution saying something like
"the resolution of issue 11 also resolves this issue.")
To section 9.3
Expressions: Change the following:
The arguments to all XPath functions defined
in this specification MUST be given as quoted strings.
to
The arguments to all XPath functions defined
in this specification MUST be given as quoted strings, except where explicitly
defined otherwise.
To section 9.4 Assignment:
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 This constraint MUST be
enforced by static analysis.
- 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 qualified name of an XSLT parameter
- Secondly an XPath
Object parameter, providing the value for the named XSLT parameter.
The WS-BPEL processor MUST enforce the pairing of
these parameters by static analysis (i.e., an odd number of parameters must
cause a static analysis error). Note that the second member of each pair can be
an XPath Expr; this is an
exception to the restriction of XPath arguments to string literals given in
section 9.3 Expressions.
- 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 come in the form of name-value pair in the argument list, as
described above. They are used to identify the XSLT global parameters by
qualified name, and to supply values for the named global parameters. The
global parameter names MUST be string literals conforming to the
definition of QName in [XML Namespaces]
section 3, and these constraints MUST be enforced by static analysis. 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).
To 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.