RE: [wsbpel] Issue - 2 - A subfunction proposal

["Yaron Goland" <ygoland@bea.com>]

See below

-----Original Message-----
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Thursday, October 30, 2003 2:34 PM
To: ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 2 - A subfunction proposal

An interesting proposal; I'd say it is certainly worth examinely more closely.

On first reading, I have few issues/questions.

1. Import name conflicts for subfunctions. Libraries of subfunctions may easily contain duplicate function names. Do we allow this (with some sort of rule about which subfunction wins), ban it (deployment-time error), or  have a way of distinguishing (qualifying) the names? 
    

This is something I have been worried about but I decided not to address it in the first proposal. I try to only bite off so many problems at once. :)

 

Personally I think the best thing to do would be to allow subfunctions to have qnames. I don't understand why the BPEL spec uses ncnames. qnames are so much nicer.

 

If we don't like qnames then we could always add a second attribute to function calls that specify an identifier for the file the function is supposed to have come from.

 

If we don't like that then we can just do collision detection and either raise an error or use a solution such as Java's classpath. I must admit that I'm not a big fan of using classpaths because I think they lead to surprises and I don't like surprises. 

1. Cannot the word 'host' be replaced by term "caller's scope"?  

I just picked a word and don't feel any attachment to it. 

1. Given the demands of serializable scopes (and the need to statically determine read and write behaviour of a scope), would it not be helpful to allow a sub-function to declare if an input parameter were "read-only" or "read/write"? This would free the sub-function from the restrictions placed on expressions to permit such static analysis.  

I am a HUGE fan of being able to specify in, out and in/out parameters. I think this is a great idea. The only reason I didn't put it into the proposal is, again, I wanted to start with something simple. 

1. XPath is supposed to be side-effect free, which implies (to me, at least) that variables passed as parameters (by reference, of course) must be read-only. 
    

I'm not sure what you mean. In what context are you referring to XPATH? 

1. If we do allow side-effects in XPath-callable functions, we might need to worry about XPath order-of-evaluation, as well as short-circuiting of logical expression evaluation, in order to assure portable behaviour. I don't believe XPath 1.0 specifies these things.  

Again, I'm not sure in what context you are referring to XPATH. 

1. I assume that a <function> activity would be a basic activity, so that <subfunction> activities could not contain start activities?
    

I suspect we will all sleep better if functions aren't allowed to be start activities. Although I could think of some ways we could make it possible I'm not sure it's worth the effort. 

Let me mull your proposal over a bit more; perhaps I can answer some of my own issues.

Cheers,
-Ron