Re: [wsbpel] Issue - 11 Your opinion requested

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Chris Keller wrote:

>That is possible. I have also solved that problem in products through
>registering global variables ($xxx). However the current specification
>doesn't state what a message context should look like to an XPath
>processor.  
>
Yes, my problem was similar. We wound up making all data "in scope" 
available as global variables, so the stylesheet author could pick and 
choose.

It would have been nice to allow renaming of variables, to decouple the 
stylesheet from the specific process definition.  Something like:

    <transform type="bpel:xslt" href="stylesheet.xslt">
       <var name="foo" transform-name="bar"/>
       <var name="baz"/>
       ...
    </transform>
   
to designate and (optionally) rename variables to be conveyed to the 
transformer.

>Instead the current specification states what a
>bpws:getVariableData context would look like to the XPath processor.
>That is why I was leaning toward using the bpws:getVariableData function
>even within XSLT.  If we can state what the $message context is
>(probably some sort of nodeset where the nodes are the individual parts)
>then we can use it instead.  If we did this then I think we could drop
>the bpws:getVariableData function altogether and use the $ notation even
>within bpel expressions.
>
Certainly the $variable type of notation is more consise, and readable, 
that extension functions. Can we define an XPath environment that 
includes the in-scope variables for expression evaluation?

-Ron