OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



Hi all,

What a meaningful discussion! :-)  [I really hope we can get something constructive out of this discussion. I agree with Ron that the proposal we have today is 80% finished already.]

Ok. Let me sum up my further viewpoints and clarification after reading all these emails from you guys:

(A)
Alexandre Alves wrote:

Alex,

 

Let me see if I understood it: you are basically stating that the XSL URI must be resolved before runtime and that the resolved resource must not change after resolution, is that correct?

 

Yes, that is what I meant, if we decide to use that URI in compile time **ONLY**. If we want to adopt Ron's preferred model, XSLT will be incorporated and "embedded" as a part of BPEL definition during compile-time / deployment-time. That will be similar to the cases of XSD and WSDL, as Ron and Chris also pointed out.

Is there anything particularly wrong in this approach? No. As long as we spell out this semantics clearly (see more below) in the proposal and the majority of TC agrees with it, I am OK with it.

(B)
Before we run into the details of this doXSLTransform() function signature, I think we should deal with the CORE question first - i.e. When is XSLT being analyzed by BPEL processors?

And, there are multiple possibilities:
  • compile-time-only
  • runtime-only
  • both compile time and runtime

Compile-time-only seems to point to Ron's preferred approach.

Runtime-only seems to point to the other approach listed in Ron's yesterday email. That is, BPEL processor does not know at compile time which variables needed to be passed to XSLT processor by analysing XSLT definition, unless users specifies those variables in other parts of function signature. But, that allows runtime flexibility of XSLT.

The third brand new approach would be (thinking out loud here): both compile time and runtime:
  • The XSLT will be analyzed at compile time to gather these global parameters and being stored as a part of process definition
  • This compile-time parameter list will be passed to doXSLTransform() function as a part of BPEL execution context (which is also used to resolve any BPEL varaible)
  • The XSLT MAY be analyzed again at runtime to gather the runtime parameter list. If the runtime parameter list is superset of compile time parameter list. An fault MUST be raised.

    [ I want to stress the MAY word here, because most of the cases XSLT do not change after compilation. If we enforce all implementation MUST re-analyse XSLT all the time, the XSLT will become too expensive. When / / whether to re-analyze the XSLT again at runtime should be implementaiton specific configuration parameters, as people want to cach their XSLT related resources at runtime. ]

With this approach, it seems to me that we can achieve brevity that Ron prefers and runtime flexibility of what Chris wants. At the same time, would it be too difficult / subtle for BPEL users to grab the concept of "compile-time parameter list vs runtime parameter list"? At the same time, this kind of concept exists for quite a while, Win DLL (missing entry point error) and Java Class (incompatible method).

(C)
I believe that we may want to hold a "directional" vote first (maybe tomorrow) to decide which way we want to go. Then, we can craft out the detailed spec text for that section.

(D)
Clarification:
Ron wrote:
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')

Actually, in my previous (offline) email, I was suggesting NOT matching parameter by position. I was suggesting we should stick with matching parameter by name. That is, there would be XSL parameters named after "Item", "Price" and "Qty".


I hope you guys find the data points in this email useful in your thinking for this issue.


Thanks!


Regards,
Alex Yiu



Ron Ten-Hove wrote:
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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]