Re: Structuring the discussion points

[Michael Weber <mweber@informatik.hu-berlin.de>]

Dear Olaf, dear colleagues,

I distinguished objects and labels 
(see http://www2.informatik.hu-berlin.de/top/PNX/archive/msg00002.html).
Maybe "label" is not the right term for those things in nets
which are not the net itself, a place, a transition, or an arc.
How do we name these "things"?  Any suggestion is welcome.

Olaf Kummer wrote:
> 
> 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.)

I think the offset position should be stored, because the 
inscription is related to a certain object which has a position.
Maybe, there are tools rearranging the position of a node but
leaving the position of the inscription in relation to the node.

>  - size

The size is a number (whithout unit) related to the underlaying
grid, isn't it?

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

The last one.

> Then:
>   inhibitor
>   clear
>   flexible arcs (multiset valued)
> I know that several formalisms do not need to indicate
> flexible arcs explicitly.

Maybe, an explicit flexible arc simplifies a transformation
process.

> >         * 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?

How many of those operations do we need?
How about negative results?

> > Level 1:
[...]
> >         * more graphic features
> 
> I am not sure if splitting the graphics requirements
> makes much sense, but some less important graphics would be
[...]

Maybe, I was wrong to put the graphics into the levels.
But, we should fix the semantic and the syntax of those graphical 
features which are shared by different tools.  Some of these
features are highly recommended, other not.  I suggest to prepare
a list sorted by urgency of the recommendation.

Kind regards

Micha
-- 
Michael Weber                       4.4.15 | Institut fuer Informatik   
mweber@informatik.hu-berlin.de             | Humboldt-Universitaet
Tel. +49-30/2093-3075, -3066               | Unter den Linden 6
http://www2.informatik.hu-berlin.de/~mweber | D-10099 Berlin