Hi Ron,
Yes, makes sense. Thanks.
I am not sure if editing will add the
examples to the spec, but if they do, can I suggest changing one of the
examples to use a namespace prefix:
<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,
"bpws:NewItem", $OutVar)
</expression>
</from>
<to variable="PO"/>
</assign>
</sequence>
</while>
<xsl:transform version="1.0"
xmlns:bpws=”…”
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<!-- NewItem variable set by
BPEL process; defaults to empty
item
-->
<xsl:param name = "bpws:NewItem"><item/></xsl:param>
...
</xsl:transform>
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Wednesday, October 26, 2005
6:01 AM
To: Alexandre Alves
Cc: wsbpeltc
Subject: Re: [wsbpel] Issue - 11 -
Proposed Resolution for 10/26 meeting
Alexandre Alves wrote:
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…
A very good point. We have two different precedents
here. I think your idea of supporting the XPath/XSLT precedent is the most
pragmatic. We will need to add a clarification to the description of doXslTransform.
Something like:
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.
to
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. Null prefixes MUST be handled as specified in [XSLT 1.0] section 2.4.
where the bold text indicates the addition to be made.
Does this make sense to you?
-Ron
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.