Re: [wsbpel] Issue - 157 - Proposal For Vote

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

Yaron,

    It's time for me to confess: I do have some expertise in XSLT 1.0, and even have a patent related to XSLT transformation engine implementations. I'm a bit rusty, given that I did most of my XSLT work in late '99, as the 1.0 spec was being finalized.

    XSLT 1.0 and XPath 1.0 are closely related. Our current work in fleshing out the alignment between XPath 1.0 and WS-BPEL 2.0 actually paves the way for XSLT rather nicely. I am certainly not unduly concerned about ship risk on technical grounds; I am concerned that such a late introduction (reintroduction, really) of this idea will necessarily cause some slip, if only because this will take time to collectively understand how this idea should be specified, and what impact it may have on other bits of the spec. (E.g., do we specify standard faults for standard XSLT processing errors?)

    Working out the viability and implications of this idea is not best done by "a committee of the whole", as they say in parliament. Might I suggest that we draft a smaller group, with reasonable background and interest in this proposal, to huddle together and work out the details of this proposal in a quieter fashion, that won't disrupt the workings of the whole TC? (Given my background in XSLT 1.0, I certainly am willing to participate in such a group.) The group should answer two basic questions:

• Is use of XSLT 1.0 in BPEL <assign> a viable idea?
• If the answer to the first question is "yes", then what form (or possible forms) can this take?
  

Ideally the group should create a single proposal (or a thumbs-down to the notion), giving the TC much less (if nothing) to chew on.

    Is this a viable idea, or is it too late in the game to bother?

-Ron

Yaron Y. Goland wrote:

Executive Summary: We shouldn't go for a XSLT approach without formally re-opening issue 48. We also shouldn't kid ourselves (as I did to myself yesterday), we don't know what we don't know about XSLT+BPEL and we will be using XSLT in a potentially novel way. This is a huge ship risk to the spec. Upon reflection I believe the least awful option is to just finish copy as is.

Long Winded Version:

I find myself having to agree with Alex on a number of points.

1 - We did consider exactly this suggestion in issue 48 and it was rejected. Of late we have made a big deal of not undoing previous decisions without due process. I would therefore argue that we shouldn't close issue 157 using a XSLT based solution without some kind of formal decision to re-open 48.

2 - Yesterday I was really happy to use the XSLT solution because it gets me out of the copy business and would make issue 11 go away. But I now realize that I was kidding myself. We don't know what we don't know about XSLT where as we know a lot about the current copy proposal. In terms of 'time to completion' the best choice was to get rid of copy but the group soundly rejected that. So we can either adopt XSLT or finish copy.

    Adopting XSLT sounds nice (to me at least) because we can inherit a bunch of functionality but the reality is that we would be using XSLT in a potentially novel way and in general we as a group don't have a deep understanding of all the gotchas in embedding XSLT in BPEL.

    I would remind the group that it took us a full year to embed XPATH into BPEL and that was a much simpler challenge. What took all that time wasn't just figuring out how to represent WSDL messages, that was more a political than technical issue. What really took all the time was figuring out every possible connection point and how to deal with it.

    Right now we know a lot about XPATH, the infoset and Copy, therefore we are in a reasonably good position to define Copy using those technologies. We don't know what we don't know about XSLT+BPEL and I suspect as we learn we will find many issues and problems that will take us quite some time to figure out.

    If our goal is to ship this spec I suspect there is much less risk in copy than in XSLT.

So I find myself having to reverse my position from yesterday, I propose we stick with the current copy approach.

        Yaron