Mailing-List: contact dev-help@ode.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ode.apache.org
Received-SPF: pass (athena.apache.org: domain of matthieu.riou@gmail.com
 designates 74.125.46.29 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:references:x-google-sender-auth;
        b=P0b6n6IDK1ToZP2uC2H0uQeWrqPabGoAKLCEEiosdVto+Zar+i+vLrrtw//D/+FbB5
         3hvuk4g0uxuxhqBrACC1RzRosNqrcT0vCYchXumx1gQrnr33Is5NWGYjNbSSH6VtV/hn
         nt1U/Bw6f/5f1Er+IP8m/E1E3acRbnq5edAHU=
Message-ID: <fbdc6a970806051712o7651ba58x6b289078afbbaef3@mail.gmail.com>
Date: Thu, 5 Jun 2008 17:12:42 -0700
From: "Matthieu Riou" <matthieu@offthelip.org>
Sender: matthieu.riou@gmail.com
To: dev@ode.apache.org
Subject: Re: Syntax of links in simPEL
In-Reply-To: <-591031083852088428@unknownmsgid>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_3557_6117425.1212711162236"
References: <-591031083852088428@unknownmsgid>

------=_Part_3557_6117425.1212711162236
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Thu, Jun 5, 2008 at 5:20 AM, Oliver Kopp <
oliver.kopp@iaas.uni-stuttgart.de> wrote:

> 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.
>

I'm not sure I'm completely following so please forgive me if I'm off base
and feel free to correct me. My understanding of what you're saying is that
the way one could understand the snippet above is not the way it actually
is. Hence it should be fixed because it's ambiguous. Is that right?

However, when I read your explanation, you're interpreting everything in
terms of links, sourcing and targeting. What we have here aren't links, we
have a signal construct and a join construct. Signal says when something is
done, join says when we should hold until something is done. In  that light
I don't think one would get mislead. So if I just change labels in your
example:

parallel {
  put-pizza-in-oven;
  pizza-cooked;
 signal(diner-ready);
} and {
 join(diner-ready, "beer.temperature < 10c");
  get-beer-in-fridge;
  drink-beer;
}

I won't drink my beer as long as the diner's ready and even when it's ready,
I still won't drink it if it's not freshed. I don't think one would expect
drink-beer to execute if both conditions aren't satisfied.

Or did I completely misunderstood what you were saying?


> 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? :))
>

Are you afraid of people making too many typos? ;) Actually without writing
anything about it we're already number 5 on Google so I'm not too worried
about Googleability (I'm so going to get sued for trademark on this one).

http://www.google.com/search?hl=en&q=simpel&btnG=Google+Search

Matthieu


>
> Cheers,
>
> Olly, Tammo
>
>
>

------=_Part_3557_6117425.1212711162236--