[September 23, 2000] A research team at Humboldt-Universität zu Berlin has developed a proposal for an interchange format 'Petri Net Markup Language' in support of software tool interoperability. This research represents one part of a larger collaborative effort by scientists in several countries to create an XML-based standardized interchange format for Petri nets. Following a meeting in June 2000 (Meeting on XML/SGML based Interchange Formats for Petri Nets - 21st International Conference on Application and Theory of Petri Nets Aarhus, Denmark, June 26-30, 2000), a mailing list was formed to manage the discussion. Resulting from the ICATPN 2000 meeting, seven "position papers" (some with accompanying slides) and four "detailed proposals" for descriptive markup encoding are now available online. It is hoped that a standardisation effort will be approved by October 2000, and that a preliminary interchange format can be drafted by the end of 2000; the format should be compatible with ISO/IEC 15909. The Petri Net Markup Language (PNML) is "a preliminary proposal of an XML-based interchange format for Petri nets. Originally, the PNML was intended to serve as a file format for the Java version of the Petri Net Kernel. It turned out that currently several other groups are developing an XML-based interchange format too. So, the PNML is only one contribution to the ongoing discussion and to the standardization efforts of an XML-based format. The specific feature of the PNML is its openness: It distinguishes between general features of all types of Petri nets and specific features of a specific Petri net type. The specific features are defined in a separate Petri Net Type Definition (PNTD) for each Petri net type. In its current version, the PNML demonstrates that an XML-based interchange format can be defined in a generic way. What features are considered to be so general such that they must be included in the PNML, and what features are considered to be specific to a particular net type is subject to further discussion..." The project web site supplies description of PNML, an XML schema, several PNTD for different Petri net types, and some examples.
Position paper: "The Petri Net Markup Language." 6 pages, with 6 references. By Matthias Jüngel, Ekkart Kindler, and Michael Weber (Humboldt-Universität zu Berlin; email: {juengel|kindler|mweber} @informatik.hu-berlin.de). 31-August-2000. To be presented at the 'Workshop Algorithmen und Werkzeuge für Petrinetze, Koblenz University, Germany, 2000. ['A position paper which argues in favour of a generic interchange format and discusses the basic idea of PNML.'] "At the "Meeting on XML/SGML based Interchange Formats for Petri Nets" held in Aarhus in June 2000, different aspects of interchange formats for Petri nets were discussed, requirements were identified, and several interchange formats were proposed. Here, we present an interchange format for Petri nets that is based on this discussion and on our preliminary proposal. We call it the Petri Net Markup Language (PNML). The proposed format is quite basic, but it is open for future extensions. In this paper, we present the concepts and terminology of the interchange format as well as its syntax, which is based on XML. It should provide a starting point for the development of a standard interchange format for Petri nets. Concepts and terminology: Before introducing the syntax of the interchange format, we briefy discuss its basic concepts and terminology, which is independent of XML. . . A file that meets the requirements of the interchange format is called a Petri net file; it may contain several Petri nets. Each Petri net consists of objects, where the objects, basically, represent the graph structure of the Petri net. Thus, an object is a place, a transition, or an arc. For structuring a Petri net, there are three other kinds of objects, which will be explained later in this section: pages, reference places, and reference transitions. Each object within a Petri net file has a unique identifier, which can be used to refer to this object. For convenience, we call places, transitions, reference places, and reference transitions nodes, and we call a reference place and a reference transition a reference node. In order to assign further meaning to an object, each object may have some labels. Typically, a label represents the name of a node, the marking of a place, the guard of a transition, or the inscription of an arc. The legal labels -- and the legal combinations of labels -- of an object are defined by the type of the Petri net, which will be defined later in this section. In addition, the Petri net itself may have some labels. For example, the declaration of functions and variables that are used in the arc-inscriptions could be the labels of a Petri net. We distinguish between two kinds of labels: annotations and attributes. Typically, an annotation is a label with an infinite domain of legal values. For example, names, markings, arc-inscriptions, and transition guards are annotations. An attribute is a label with a finite (and small) domain of legal values. For examples, an arc-type could be a label of an arc with domain: normal, read, inhibitor, reset (and maybe some more). Another example are attributes for classifying the nodes of a net as proposed by Mailund and Mortensen. Besides this pragmatic difference, annotations have graphical information whereas attributes do not have graphical information. [...] The available labels and the legal combinations of labels for a particular object are defined by a Petri net type. Technically, a Petri net type is a document that defines the XML-syntax of labels; i.e., either a DTD-file or an XML-Schema. In this paper, we concentrate on a single Petri net type: a Petri net type for high-level Petri nets. In principle, a Petri net type can be freely defined. In practice, however, a Petri net type chooses the labels from a collection of predefined labels, which are provided in a separate document: the conventions. The conventions guarantee that the same label has the same meaning in all Petri net types. This allows us to exchange nets between tools with a different, but similar Petri net type. . . we present some concrete XML syntax in order to exemplify the concepts discussed in Sect. 2. Here, we can only give a flavour of PNML by examples. The examples are pieces of a PNML-coded document representing a Petri net. The examples refer to the PNML version 0.99. In PNML, the net, the Petri net objects, and the labels are represented as XML elements. An XML element is included in a pair of a start tag <element> and an end tag </element>. An XML element may have XML attributes in order to qualify it. XML attributes of XML elements are denoted by an assignment of a value to a key in the start tag of the XML element <element key="value">. XML elements may contain text or further XML elements. An XML element without text or sub-elements is denoted by a single tag <element/>. In our examples, we sometimes omit some XML elements. We denote this by an ellipsis (...). The tags of the following XML elements are named after the concepts given in Sect. 2 except for the labels. Labels are named after their meaning. Thus, an unknown XML element appearing in a Petri net or in an object may indicated as a label of the net or the object..." [cache]
References:
The larger picture: "XML and Petri Nets."
"Towards a Generic Interchange Format for Petri Nets," by Matthias Jüngel, Ekkart Kindler, and Michael Weber. [cache]
Petri Net Markup Language Schema - Draft available as of 2000-09-23. See also the download file. [cache XSD, cache XSD and examples]
AWPN Workshop (Algorithmen und Werkzeuge für Petrinetze, 2. - 03. Oktober 2000, Universität in Koblenz)
PNML contacts: Matthias Jüngel or Michael Weber
[March 2003] "The Petri Net Markup Language: Concepts, Technology, and Tools." By Jonathan Billington, Søren Christensen, Kees van Hee, Ekkart Kindler, Olaf Kummer, Laure Petrucci, Reinier Post, Christian Stehno, and Michael Weber. Preliminary version of a submission to the conference proceedings of the ICATPN 2003, Eindhoven, Netherlands, June 2003. "The Petri Net Markup Language (PNML) is an XML-based interchange format for Petri nets. In order to support different versions of Petri nets and, in particular, future versions of Petri nets, PNML allows the definition of Petri net types. Due to this flexibility, PNML is a starting point for a standard interchange format for Petri nets. This paper discusses the design principles, the basic concepts, and the underlying XML technology of PNML. The main purpose of this paper is to disseminate the ideas of PNML and to stimulate discussion on and contributions to a standard Petri net interchange format." [cache]
[December 27, 2002] "The Petri Net Markup Language." By Michael Weber (Humboldt-Universität zu Berlin, Institut für Informatik) [WWW] and Ekkart Kindler (Technische Universität München, Fakultät für Informatik). April 2002. 21 pages. ['This paper describes the motivation and the realization of the Petri Net Markup Language. A draft was submitted for publication in the volume Petri Net Technology for Communication Based Systems within the LNCS series "Advances in Petri Nets".'] "The Petri Net Markup Language (PNML) is an XML-based interchange format for Petri nets. PNML supports any version of Petri net since new Petri net types can be defined by so-called Petri Net Type Definitions (PNTD). In this paper, we present the syntax and the semantics of PNML as well as the principles underlying its design. Moreover, we present an extension called modular PNML, which is a type independent module concept for Petri nets... The main feature of PNML is its universality, which is achieved by representing a net as a labelled graph along with a Petri Net Type Definition. The Petri Net Type Definition defines the legal labels for a particular Petri net type. The definition of modular PNML shows that universality carries over to a module concept, which can be used with any Petri net type. This way, PNML provides a way to exchange Petri nets between different tools without loosing too much information. PNML itself is now in a stable state. Currently, it is supported by the PNK [Petri Net Kernel] and Renew [Reference Net Workshop tool]. For a broader acceptance, we need a standardized set of Petri net types and a standardized set of labels, which covers most of the existing versions of Petri nets. PNML provides a mechanism for defining Petri net types and for using labels from a conventions document. The Petri net types and the conventions document, however, are not part of PNML. The development and the standardization of the conventions document is an on-going process, which requires further research and interaction among researchers..." [cache]
