RE: [wsbpel] Issue - 11 - Proposed Resolution for 10/19 meeting

["Chris Keller" <chris.keller@active-endpoints.com>]

Ron,

 

Even if there is no direct must directive in the specification there are implied musts.  The example of an implementation must do something with regard to WSDL and Schema handling is one.  On the level of the expression languages we have an implied must. The expression language handlers must be able to return a list of variables it will access so that a scope can be properly isolated.  This is true because isolated scopes are mandated by the specification.  As for the new transform function call there are many ways to implement this implied contract.  But I think we should be mindful to the fact that isolated scopes are designed to be deadlock free and so implementations which don’t cache the stylesheet it processed for variable identification could be hazardous.  Now as a user if I want to make a change to the stylesheet I have to do it in a way that the BPEL processor knows to refresh itself.

 

Ok, so now on to how we make the passing of parameters via the function call better.  I don’t like the naming convention approach (param1, param2, …).  What if instead we alternated the name and the value like so:

 

doXslTransform('urn:sheets:foo.xsl', $PO, 'Item', $Response.detail.item[1],

                                          'Price', 10,

                                          'Qty', 3)

 

So the definition would be:

 

doXslTransform( uri, source [, paramQName, param]*)

 

This allows you to pass many parameters and makes it trivial if you are only trying to transform the source which probably represents most of the use cases.

 

- Chris

---

From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Tuesday, October 18, 2005 6:05 PM
To: chris.keller@active-endpoints.com
Cc: 'Alex Yiu'; 'wsbpeltc'
Subject: Re: [wsbpel] Issue - 11 - Proposed Resolution for 10/19 meeting

 

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