Re: Structuring the discussion points

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

Dear Michael, dear all,

Michael Weber wrote:
> 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.

"inscription"
"annotation" (was suggested earlier with a hint to the PN standard)
"region" (Design/CPN usage)

Currently, annotation is my favourite, but I don't really care.
We should simply decide fast. It does not matter. (Is there a 
simple procedure for voting on questions where everybody
would be happy with everything?)

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

I agree.

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

The unit would be pixel or grid width then, wouldn't it?

Some tools can set different sizes in x- and y-direction.
Some cannot. Let me make a suggestion:
  - There are three elements: xsize, ysize, and size.
  - Tools export xsize if and only if they export ysize.
  - Tools that export xsize should also export a sensible
    value for size.
  - Tools may export size alone.
  - Tools may import xsize and ysize, ignoring size.
  - Tools may default missing xsize and ysize elements to size.
  - Tools may use size instead of xsize and ysize.
  - Tools should be robust enough to ignore missing values.
    (This applies in general. *All* missing values should be 
    defaulted, possibly tool dependent.)

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

Fine.

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

Ok, then let me summarize the list again:
  normal
  inhibitor
  reserve (or do you prefer "inout" or "double"?)
  read (probably the more common term, then)
  inhibitor
  clear
  flexible-normal
  flexible-reserve
  flexible-read
Any additions?

> > >         * 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></semantics>
> > </label>
> > What do you think?
> 
> How many of those operations do we need?

Good question regarding the <semantics> element...

This seems to be very much dependent on the net formalism.
For level 0, we might get away with allowing any content
within the <semantics> element. Higher levels should then
make some suggestions how to get different formalism into 
sync as far as possible.

(I am not sure that I can support the element in my 
implementation at all, but I have been convinced that it is
a good idea to have such a preparsed representation of
the labels/inscriptions/annotations/regions. We should
at the very least provide a space where they can be put
in the form of the <semantics> element.)

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

Ok, let me restate my very personal list of graphical features,
important ones first.
 - positions of places and transitions
 - (relative) positions of labels
 - intermediate points of arcs (probably absolute)
 - colours
 - text size
I guess others would like
 - line style
 - line thickness
 - curvature radius for arcs
 - ...

It's your turn! Best to you,

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