See
below
-----Original Message-----
From: Ron Ten-Hove
[mailto:]
Sent: Thursday, October 30, 2003
2:34 PM
To:
Cc:
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.
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.
Cannot the word 'host' be replaced by term "caller's scope"?
I just
picked a word and don't feel any attachment to it.
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.
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 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
