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
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:
I just wanted to make sure I understood your meaning, not nit-pick
terminology. Host is easier to parse.
An interesting proposal; I'd say it is certainly worth examining more
On first reading, I have few issues/questions.
- 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)
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
- Cannot the word 'host' be replaced by term "caller's scope"?
I just picked a word and don't feel any
attachment to it.
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.
- 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.
That was my take on the issue; I'm not sure if pre-packaged or
otherwise reusable process starters would be terribly popular.
- 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?
- 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.
- I assume that a <function> activity would be a basic
activity, so that <subfunction> activities could not contain
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