Hi,
We have thought about the syntax of links. As we understand, join and signal
belong to the previous element.
Assume following example:
parallel {
a;
b;
signal(b-to-X);
} and {
join(b-to-X);
c;
d;
} and {
e;
signal(e-to-f);
f;
join(e-to-f);
}
The link b-to-X connects b and the sequence s2, which contains c and d.
The link e-to-f connects e and f in the sequence s3, which contains e and f.
The link b-to-X is NOT sourcing from sequence s1, which contains a and d.
However, it can be understood like that, because it is the last statement in
the sequence.
The link b-to-X is NOT targeted at c. However, it can be understood as is,
because first links are joined and then an activity is executed. I.e., join
on b-to-X and then execute c. - In the above example both interpretations
lead to the same execution. But if there is a join condition put on the
join(b-to-X), then it is not the same semantics: Assume join(b-to-X,
false()), then in the above example, c and d are both not executed, since
the join condition of the sequence evaluates to false(). If the other
interpretation is assumed, c does not get executed, but d: The sequence is
enabled and only c joins on the incoming links.
We have following different proposals: The syntax is inspired by LaTeX,
where optional arguments can be put in square braces "[...]"; We do not want
to use additional curly braces "{...}" to have the links distinguishable of
"real" arguments.
1. Proposal: Our favorite. Reflecting the execution order.
[join(...)]? activity [signals]?;
parallel {
a;
b [signal(b-to-X)];
} and [join(b-to-X)] {
c;
d;
} and {
e [signal(e-to-f)];
[join(e-to-f)] f;
}
2. Proposal: Everything before the activity.
[join(...)?, signals?]? activity;
parallel {
a;
[signal(b-to-X)] b;
} and [join(b-to-X)] {
c;
d;
} and {
[signal(e-to-f)] e;
[join(e-to-f)] f;
}
3. Proposal: Everything after the activity. (As it is now, but with
brackets).
Activity [join(...)?, signals?]?;
parallel {
a;
b [signal(b-to-X)];
} and {
c;
d;
} [join(b-to-X)] and {
e [signal(e-to-f)];
f [join(e-to-f)];
}
What do you think?
BTW, could we name simPEL "simBPEL" to enable googling for it? :-) (And
doesn't describe sim(B)PEL *B*usiness Processes? :))
Cheers,
Olly, Tammo
