Re: How to exchange high level net annotations

[Olaf Kummer <kummer@informatik.uni-hamburg.de>]

Hello Ekkart, hello all!

you wrote:
> 1. There was some discussion on "flexible arcs".  Though I am
>    in favour of having flexible arcs, I don't consider it as
>    an attribute of the arc itself---in contrast to inhibitor or
>    read arcs:
>    It depends on the annotatation (arc-inscription) whether
>    an arc is flexibel or not.  Thus, it depends on the constraints
>    on annotations whether an arc is flexible or not (cf.
>    contribution of Karsten Schmidt).
> 
>    Therefore, I propose to delete all kinds of flexible arcs from
>    the list of arc-types and make it an issue of high-level
>    inscriptions, which is my next issue.  (However, there
>    could be a different kind of label indicating that the arc is
>    flexible---as proposed by Karsten Schmidt. This would help those
>    tools that are not able to interprete the arc-inscriptions.)

and later on:
> [some standard function definitions deleted]
>       inj : s -> Bag(s)                (makes an element of
>                                         s a singleton bag)
>       * : nat Bag(s) -> Bag(s)         (scalar multiplication)
>       count : Bag(s) s -> nat          (counts the number of
>                                         occurrences of some
>                                         element of s in a bag
>                                         over s)
> 
>    Maybe, there could be some addiional conventions.  For example,
>    a term t of sort s could be considered as inj(t) if a
>    bag over s is expected ...

These two parts are related. If we allow an automatic
conversion of elements to bags, then it is of course
irrelevant whether an arc is flexible: In essence all 
arcs are flexible.

But there are other formalisms where one wants do
decide whether to put multiple tokens on a place
(denoted by a bag expression) or a single token
that represents an entire bag (also denoted
by a bag expression). If we do not distinguish
normal and flexible arcs, such formalisms will not
be able to make use of the standard.

But let me repeat. You wrote
>    ...  However, there
>    could be a different kind of label indicating that the arc is
>    flexible ...
and this offers an alternative solution.

Do you mean that you would like something along the lines of 
  <arc type="in" place=... trans=...>
    <label type="expression"><text>x</text>...</label>
    <label type="flexible"/>
  </arc>
instead of
  <arc type="flexiblein" place=... trans=...>
    <label type="expression"><text>x</text>...</label>
  </arc>
? (If you do not mind an example.)

This would be possible, of course, but the only reason to use
the more complex upper form would be tools that actually use a 
textual annotation that has a position, a font size etc. to denote 
a flexible arc. Then it would probably be
  <arc type="in" place=... trans=...>
    <label type="expression"><text>x</text>...</label>
    <label type="flexible"><text>flex</text><graphics>...</graphics></label>
  </arc>
Are there such tools? If yes, use the complex form. If no,
use an arc type.

Yours, Olaf
-- 
Olaf Kummer, Luruper Weg 21, 25469 Halstenbek, Germany
Tel: 04101-473957 / 040-42883-2245    Fax: 040-42883-2246
mailto:kummer@informatik.uni-hamburg.de
http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/wimis/kummer.html