Re: Structuring the discussion points

[Olaf Kummer <olaf@renew.de>]

Dear Michael, dear colleagues,

I am commenting of some points and leave other
to the experts in thode fields...

> I distinguish
>         net objects (net, places, transitions, and arcs)
> and
>         labels related to objects
>                     (e.g. markings to places,
>                           guards to transitions
>                           declaration to net
>                           ...)
> 
> Level 0:
>         * Layout, graphical information
>           (we should prepare a list of minimal requirements,
>            according to both net objects and labels)

What I consider sensible as minimal graphical attributes:
 - position of the center for transitions and places.
   (The center position will be easier to set for those tools
   that do not allow to resize net elements.)
   For inscriptions: Do we want to store offsets or absolute
   positions? (I do not mind.)
 - size
 - intermediate points for arcs
Even these should be optional, but highly recommended.

>         * meaning of different arcs
>           (normal, inhibitor, read, ... (which else))

I have:
  normal,
  inhibitor,
  reserve (short notation for 1 in and 1 out),
  test (*no* arrowheads, may share a token
    with other transitions)
Which of the last two is your read arc? I do not
cling to my names.
Then:
  inhibitor
  clear
  flexible arcs (multiset valued)
I know that several formalisms do not need to indicate
flexible arcs explicitly.

>         * multi-set notation
>           (BTERMS in the standard ISO 15909)

Do you mean that in the form of preparsing inscipritons
and splitting them into multiset expressions?

It might be worthwhile to investigate
Karsten's idea in addition: Try to determine
at least the number of tokens.

>         * labels as pure text
>           (the developers are free to substructure the labels,
>            but a pure text of a label is required, too)

Maybe in the spirit of
<label type="expression">
  <text>bla+bla</text>
  <graphics>...</graphics>
  <semantics><add><var name="bla"/><var name="bla"/></add>
</label>
What do you think?

>         * structuring concept
>           (which?)

This is one point where prototypes would come in handy.
I can accept any solution as long as additional
concepts can be added later.

>         * types of net objects
>           (see the different arcs above;
>            maybe there are types for transitions and places,
>            e.g. external transitions in Reisig (1998))

Maybe:

<arc type="read">

>         * user defined classes of net objects
>           (in order to separate them in special style sheets,
>            e.g. to distinguish transitions of a client from
>            transitions of the server)

I think assigning a class to net objects would 
be useful. Something like

<arc type="read" class="valueableresource">
...

> Level 1:
>         * more syntax for labels
> 
>         * fixed semantics for tokens, etc.
> 
>         * more graphic features

I am not sure if splitting the graphics requirements
makes much sense, but some less important graphics would be
 - color (fill, outline,...)
 - Z-order
 - arc curvature
 - line styles
Indicating Z-order (which figures go on top of each other)
by the order of XML elements would make creation and parsing
more difficult, I guess. An explicit ordering might
be easier. What do you think?

>         * properties of nets
> 
> Level 2:
>         * transformation between different high-level formalisms

As a mean of defining the semantics as in the PN standard?
Does this affect the file format? Do we need to make certain
assumptions to make these translations feasible?

Olaf