The basic structure of XML PN files

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

Dear all,

following the advice of Karsten, I'll try to spawn of 
another thread for an individual topic. (Although this
mailing list would be unique if subject headers showed 
any correlation to content for threads longer than two 
messages ...)

It has already turned out that certain pieces of information
need to be represented by the XML file format:
 - net topology (place, transitions, arcs)
 - textual representation of annotations
 - semantical representation of annotations (see essay by
   Karsten)
 - layout and graphics
 - net element classes as suggested by Thomas at the ICATPN
   for enabling style sheets. The user could e.g. denote
   that a certain inscription was added by Joe or that
   a place is used for control flow,
 - things I missed.

Most important question: Does all this information reside in
one file or is it split into multiple files?

My personal opinion is that we should avoid multiple files,
if at all possible. In a different project, a group at our 
university experimented with split files for graphics and
semantics. It turned out difficult to implement and not 
exactly robust. 

We should try to find a consensus in this respect,
because this decision will affect other discussions
severly. I invite any comments on this matter, so that 
we can determine if this question is open at all. 
Maybe we agree already. Maybe not.

Second question: Should it be possible to store multiple
nets in one file? My opinion is now that this should be 
possible, contrary to the solution in my prototype.
After some discussions at Aarhus, it seems that this would
be helpful to a few people and it would not add much to
the complexity.

Third question: If stored in a single file, does the 
graphics go side-by-side with the topology or do we nest
topology within graphics or graphics within topology.

Let me show an example. (I always think it is a good idea 
to flesh out ideas by an example XML file, if a full-blown 
prototype implementation is not possible.)

<place id="P12341234">...</place>
  ...
<circle ref="P12341234">...</circle>


<circle id="P12341234">...</circle>
  ...
<place ref="P12341234">...</place>


<circle>
  <topology><place>...</place></topology>
  ...
</circle>


<place>
  <graphics><circle>...</circle></graphics>
  ...
</place>


I prefer the last version, because it is simplest
for the non-graphical tools to ignore the graphical 
information.

In fact, I mentioned multiple types of information
and all of these would have to be represented. E.g.:

<annotation>
  <text>frobozzify()</text>
  <graphics><color>red</color></graphics>
  <semantics><function name="frobozzify"></function></semantics>
  <classes><class>Joe</class><class>control</class><classes>  
  ...
</annotation>

Here, too, it is simple to ignore unneeded information.
It is also clear which elements belong to each other.
Moreover, every conceivable PN tool requires the net
topology, so this element might as well stay on top.

(BTW: Let's discuss how to represent graphics
in a different thread. The above examples are merely
intended to show where the graphics would go.)

Comments anyone? 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