[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]

[November 20, 2003]Event-Driven Process Chain Markup Language (EPML) for Business Process Modeling. A communiqué from Jan Mendling (New Media Lab, Vienna University of Economics and Business Administration) describes the progress of a standardization initiative within the EPC Community, focused upon development of an Event-Driven Process Chain Markup Language (EPML). Event-Driven Process Chains (EPCs) are a method for representation of business process models, popular especially in Germany. EPML is motivated by the goal of supporting data and model interchange in the face of heterogenous Business Process Modeling tools. The chief design principles in EPML are "readability, extensibility, tool orientation, and syntactic correctness. Readability expects EPML elements and attributes to have intuitive and perspicuous names. This is important because EPML documents will be used not only by applications, but also by humans who write XSLT-scripts that transform between EPML and other XML vocabularies. Extensibility reflects the need to provide different business perspectives and views on a process. EPML will be capable of expressing arbitrary perspectives instead of supporting just a pre-defined set. Tool orientation deals with graphical representation of EPCs. This is a crucial feature because BPM tools provide a GUI for developing the models. EPML will be able to store various layout and position information for EPC elements. Finally, syntactic correctness addresses EPC syntax elements and their interrelation." An initial EPML XML Schema and supporting documentation have been published.

[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]