|Ron Ten-Hove||Oct 18, 2005 12:36 pm|
|Alex Yiu||Oct 18, 2005 1:08 pm|
|Chris Keller||Oct 18, 2005 1:42 pm|
|Ron Ten-Hove||Oct 18, 2005 1:44 pm|
|Alexandre Alves||Oct 18, 2005 1:51 pm|
|Danny van der Rijn||Oct 18, 2005 1:57 pm|
|Chris Keller||Oct 18, 2005 2:07 pm|
|Ron Ten-Hove||Oct 18, 2005 2:09 pm|
|Ron Ten-Hove||Oct 18, 2005 2:23 pm|
|Ron Ten-Hove||Oct 18, 2005 3:04 pm|
|Alex Yiu||Oct 18, 2005 4:00 pm|
|Chris Keller||Oct 18, 2005 4:03 pm|
|Alex Yiu||Oct 18, 2005 6:18 pm|
|Ron Ten-Hove||Oct 18, 2005 7:39 pm|
|Ron Ten-Hove||Oct 19, 2005 5:55 am|
|Ron Ten-Hove||Oct 19, 2005 6:32 am|
|Ron Ten-Hove||Oct 19, 2005 6:56 am|
|Ron Ten-Hove||Oct 19, 2005 7:46 am|
|Subject:||Re: [wsbpel] Issue - 11 - Proposed Resolution for 10/19 meeting|
|From:||Ron Ten-Hove (Rona...@Sun.COM)|
|Date:||Oct 18, 2005 3:04:11 pm|
Chris Keller wrote:
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?