|
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:
<switch>
<case>
<condition>
<function functionName="IsAddOne">
<parameter variable="mathProblem" property="problemType"/>
</function>
</condition>
<function functionName="AddOne">
<parameter variable="mathProblem"/>
<parameter partnerLink="mathStudent"/>
</function>
</case>
<otherwise>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.
Yaron
Yaron,
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:
Regards,
-Ron
Yaron Goland
wrote:
See below
An
interesting proposal; I'd say it is certainly worth examining 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.
I just wanted to make sure I understood
your meaning, not nit-pick terminology. Host is easier to parse.
- 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.
- 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.
That
was my take on the issue; I'm not sure if pre-packaged or otherwise reusable
process starters would be terribly popular.
|