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 - 2 - Subfunctions and XPATHS

In my proposal I actually replace XPATHs with subfunctions. I do not insert one into the other. The following is a snippet from the example I sent out:
               <function functionName="IsAddOne">
                  <parameter variable="mathProblem" property="problemType"/>
            <function functionName="AddOne">
               <parameter variable="mathProblem"/>
               <parameter partnerLink="mathStudent"/>
Notice that the subfunction call replaces the traditional condition attribute on the case element with a subelement called condition whose content is a subfunction call (I think we will need to do something like this anyway for Issue 13). This is very different from the idea of having an XPATH which, along with functions such as getVariableProperty or getLinkStatus, could have a subfunction call. Although making subfunctions available for use in XPATHs is nifty I suspect it would cause more agony than it was worth. But that's just a guess.
-----Original Message-----
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Saturday, November 01, 2003 11:03 AM
To: ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 2 - A subfunction proposal


    Thanks for the reply; obviously we are thinking along the same lines in many of the aspects of subfunctions.

    My references to XPath were made due to the (to me) very interesting proposal to make subfunctions callable from expressions in BPEL. Using BPEL's default expression language (XPath 1.0), subfunctions become a form of XPath extension function, but not opaque to our BPEL language; rather they would be defined in terms of BPEL itself.

    Having built an XPath 1.0 evaluator a few years ago, I know that XPath has some restrictions on what happens during evaluation of expressions. The primary restriction is: no side effects. Thus my concern about read-only parameters; such parameters would preserve XPath's evaluation semantics.

    Some other comments in-line, below:


Yaron Goland wrote:
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 examining 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.
I just wanted to make sure I understood your meaning, not nit-pick terminology. Host is easier to parse.
  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.
Understood, and agreed. Having used languages that allow specfication of the in, out, and related properties of objects, I am sold on their benefits, across a wide range of application types.
  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.
That was my take on the issue; I'm not sure if pre-packaged or otherwise reusable process starters would be terribly popular.

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