Chris,
Chris Keller wrote:
Hi Ron,
As you know
I have the same reservations
that Alex has.
I think we
all agree that in general BPEL
expressions must be analyzed for their variable access in order to
properly
handle isolated scopes. So if one builds an expression handler it is
part
of the contract with that handler. Now we are saying that part of the
XPath
expression language handler contract is that it must also parse and
potentially
store the XSLT referenced by it as part of a function it provides.
If you are saying that this will cause changes in existing
implementations of BPEL, you are indeed correct. Given that bpws:doXslTransform, if accepted, will be an
architected function of a required expression language (much as
bpws:getVariableProperty is), then it must be appropriately supported
by tools and run-time. I don't see this as big problem; parsing XSLT
documents isn't difficult. You can even use XSLT to help analyse XSLT
documents.
It
seems that the contract implemented by the expression language handler
has now
stepped into the management of outside resources (not to say caching
can’t
be done, but caching and management are 2 different things).
We are creating a specification, and should not assume or mandate any
implementation details. It seems you are worrying about specific
implementation issues. Or do you believe these concerns to be generally
applicable to all implementations?
WSDL and
Schema on the other hand are direct
BPEL dependencies and even imported as such. If we want to put XSLT in
this same category then we should say it must also be imported so it
can be
managed by/for the BPEL.
As an architected part of the language, would the XSLT documents
referenced in the doXslTransform calls not fall into this category as
well? Or do we need to add some explicit "import" for style sheets?
I also
believe that by passing the
variables (or items within variables) as arguments to the transform
function one
could gain flexibility by being able to reuse the XSLT with different
variables.
This would require some renaming between the variables referenced and
the XSLT global parameters. Positional naming is the most
straightforward. Using Alex's preferred option 1 (a) syntax:
doXslTransform('urn:sheets:foo.xsl', $PO, 'Item',
'Price', 'Qty')
could map Item to parameter "bpws:param1", Price to
"bpws:param2", etc. This does make the style sheet less readable,
though.
<!-- Item from BPEL process -->
<xsl:param name="bpws:param1>No item</xsl:param>
...
<xsl:copy-of select="$bpws:param1"/> <!-- is really BPEL Item
-->
Or something like that. Is that what you had in mind?
Cheers,
-Ron
|