[September 23, 2000] Research at Humboldt-Universität zu Berlin 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.
References:
PetriNets - Petri Net FAQ, Petri Nets Standard ISO/IEC FCD 15909
Petrinets.org "Petri Nets: a formal, graphical, executable technique for the specification and analysis of concurrent, discrete-event dynamic systems; a technique undergoing standardisation."
"Meeting on XML/SGML based Interchange Formats for Petri Nets." 21st International Conference on Application and Theory of Petri Nets [ICATPN 2000]. Aarhus, Denmark, June 26-30, 2000. [cache, summary]
Position Papers presented at ICATPN 2000, June 2000. [cache]
Mailing list PNX for discussing the standard Interchange Format for Petri Nets, with archive. There are several XML proposals as of 2000-09-23.
"Petri Nets and XML in Bioinformatics." By Ming Chen (Institut für Technische und Betriebliche Informationssysteme, Otto-von-Guericke-Universität Magdeburg, Germany). See also Petri Nets overview (application in bioinformatics) and Petrinets links.
[November 21, 2001] "Modeling Interorganizational Workflows with XML Nets." By Kirsten Lenz and Andreas Oberweis (Institute of Information Systems, J.W. Goethe-University). Published in Proceedings of the Hawai'i International Conference on System Sciences (January 3-6, 2001, Maui, Hawaii). Extent: 11 pages, with 21 references. "Efficient interorganizational business processes in the field of e-commerce require the integration of electronic document and data interchange and interorganizational processes. We propose to support interorganizational business processes by so-called XML nets, a new kind of high-level Petri nets. XML nets are a formal, graphical modeling language that allows to model both the flow of XML documents and the business process. XML nets are based on GXSL, a graphical XML schema definition language, and its related graphical XML document manipulation language (XManiLa). They can be directly executed by a workflow engine. Advantage of the formal foundation of XML nets can be taken e.g. when analyzing a (global) interorganizational workflow model: XML nets support the process of identifying relevant process fragments, assigning them to the appropriate organizational units, and thus help deriving an improved, process-oriented organizational structure... The XML document type definition represents a grammar for the declaration of documents. It consists of a set of markup declarations of different types: element, attribute list, entity or notation declaration. Unfortunately, this grammar is textual so that the DTDs for complex objects often may become quite unreadable. The advantages of a graphical schema definition language (like the entity/relationship model for the database design) are missing. In the following, we propose a graphical schema definition language for the design of XML document types, that we call graphical XML schema definition language (GXSL). The presented version of GXSL is DTD-based, i.e., a DTD can be unambiguously derived from the graphical XML schema (GXS). Instead of creating a completely new graphical modeling language for XML document types, we rely on well known data modeling concepts (of the E/R-model and other semantic data models), which all had their impact on the static modeling concepts of the Unified Modeling Language (UML). The main advantage of UML is that it is a highly accepted integration of well-known modeling concepts and guidelines and that it comprises a generic notation for the derivation of new graphical modeling languages for specific purposes... In this contribution, we have introduced XML-nets, which integrate behavior- and document-related aspects of workflows. In the future, GXSL might be adopted to XML schemas as soon as ongoing work on XML schemas has lead to a W3C recommendation. Moreover, XManiLa will be extended to querying the sequential order of elements of the same element class. For the geographical distribution of XML net-based workflows, principles of distributed database management systems may be transferred to the management of distributed XML documents, focussed for example on the management of document replication. Finally, criteria for the allocation of workflow fragments depending on the allocation of documents, mass data and other relevant resources must be found. We plan to extend an existing Petri net simulation tool in order to simulate and validate distributed workflows which are modeled as XML nets..." See the web site: XMLNet: Modellierung von Geschäftsprozessen im E-Business mit XML-Netzen. [alt URL; cache]
[September 23, 2000] "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]
"Separation of Style and Content with XML in an Interchange Format for High-level Petri Nets." By Thomas Mailund and Kjeld H. Mortensen (Department of Computer Science University of Aarhus, Denmark). "Style sheets have been proposed by the World Wide Web Consortium (W3C) as a means for separating presentation and content in World Wide Web documents, and they are now widely used and generally popular. In this paper we use the same idea for an XML interchange format proposal for high-level Petri nets. There are several benefits of using this design principle: It is easier to exchange content-only for non-graphics tools, and alternative styles can conveniently be replaced to make a new graphical appearance. The ideas presented in this paper are illustrated by means of examples. . . Most high-level Petri net tools can agree on the underlying mathematical model of a Petri net: a set of places, a set of transitions, a set of arcs connecting places and transitions, and some annotations describing data types and data. It is quite another matter when it comes to the graphical layout of nets. Different tools have dierent graphical attributes that can be associated with the net elements. To be able to interchange models between different tools, we would like a minimal format containing only the information found in the standard for highlevel nets, and a more format for describing graphical attributes. The latter should be extendable to include tool-specific graphical information. . . In this paper we suggest how to separate presentation and content for a high-level Petri net interchange format. We used CSS examples to illustrate the main benefits of such a design technique. However CSS is more suitable for presentation of text rather than vector graphics such as Petri nets. Hence as a future activity we propose to design a special purpose style language in the context of the interchange format activity." [cache]
CPN (XML/DSD). Michael Thornvig Mikkelsen and Kim Falk Jørgensen are developing CPN. " CPN (Coloured Petri Nets) is a graphical oriented language for design, specification, simulation and verification of distributed systems. Many different tools have been made to simulate and analyse CPN. Each of these tools have different strengths. The development of an open, tool-independent interchange format would make it possible to use all of the different tools, without having to transform back and forth between the many different formats. Among earlier attempts to make such an interchange format is a DTD (Document Type Definition), which defines the structure of a SGML document. This DTD was developed by Mailund and Lyngsø. As an example of the use of this DTD is the design/CPN tool, which is able to save and retrieve a CPN using the mentioned interchange format. The goal is to make a DSD. A DSD (Document Structure Description) defines a set of XML documents. In this case the DSD we want to produce, defines a set of XML, which will be an interchange format of CPN. Our Goal is to make a representation of CPN, which only upholds the mathematical structure of the net, and not any graphical information. Hopefully this will also result in a short position paper, to be submitted to the Meeting on XML/SGML based Interchange Formats for Petri Nets. A secondary goal is to make a study into how to modularise huge CPN. Several proposals are allready published, e.g. a hierarchical, as implementented in the design/CPN tool. See the DTD (DTD for Textual Interchange Format for Design/CPN ver. 3.1) [cache]
"Textual Interchange Format for High-level Petri Nets." By R.B. Lyngsø and Thomas Mailund [Jensen]. "In this paper a text format for High-level Petri Net (HLPN) diagrams is presented. The text format is designed to serve as a platform-independent file format for the Design/CPN tool. It is consistent with the forthcoming standard for High-level Petri Nets. The text format may also be seen as our contribution to the development of an open, tool-independent interchange format for High-level Petri nets. The text format will make it possible to move Design/CPN diagrams between all supported hardware platforms and versions. It is also designed to be a bridge to other Petri Net tools, e.g., other analysis tools which the user may want to use with Design/CPN diagrams. The proposed text format does not address any standardization for the inscription language used in the diagram. It is, however, possible to extend the format to incorporate such a standardization. The text format is designed for the exchange of Hierarchical Coloured Petri Nets but the structure is general enough to cope with other High level Petri Nets as well. The text format presented here has been implemented as part of Design/CPN version 3.1. [...] Design/CPN is a widely used tool within the Petri Net community and has been developed for more than 10 years. The tool has been used in many projects in a broad range of application areas. Design/CPN supports Hierarchical Coloured Petri Nets (CP-nets or CPNs) with complex data types (colour sets) and complex data manipulations (arc expressions and guards) - both specified in the functional programming language CPN ML. It also supports hierarchical CP-nets, i.e., net diagrams that consist of a set of separate modules (subnets) with well-defined interfaces. . . We believe however that the inscription language is a far more integrated part of each tool than the graphical layout, thus translation to and from a common inscription language was considered beyond the scope of this text format. On the other hand it was feasible to implement known standards for both naming conventions and syntax in order to make it easier for humans to read the description of the diagram. To that end we have chosen to use the terminology presented in the current version of the committee draft of the HLPN standard. This means that the entities known in Design/CPN as arc expressions, colour regions and guards are called arc annotations, type region and transition conditions, respectively. Furthermore we chose to use the SGML (Standard Generalized Markup Language) ISO standard, which will be described in Sect. 3. The structure of the text format is chosen to be based on the semantic properties rather than the graphical appearance. It is thus considered more important to know that a certain object is a place than it is to know that the object has the shape of an ellipse. We want the text format to be both general enough to be used by various different tools and specific enough to save the same information about a diagram as the binary format used so far. Different tools need to add different kinds of information to the text format, and later versions of Design/CPN will probably add to the format as well." See also the DTD. [cache]
"XML Based Schema Definition for Support of Inter-organizational Workflow." By W.M.P. van der Aalst and A. Kumar. Paper presented at the "Meeting on XML/SGML based Interchange Formats for Petri Nets," 21st International Conference on Application and Theory of Petri Nets [ICATPN 2000]. Aarhus, Denmark, June 26-30, 2000. 41 pages. "Commerce on the Internet is still seriously hindered by the lack of a common language for collaborative commercial activities. Although XML (Extensible Markup Language) allows trading partners to exchange semantic information electronically, it does not provide support for document routing. In this paper, we propose the design for an eXchangeable routing language (XRL) using XML syntax. Since XML is becoming a major international standard, it is understood widely. The routing schema in XRL can be used to support flexible routing of documents in the Internet environment. The formal semantics of XRL are expressed in terms of Petri nets and examples are used to demonstrate how it can be used for implementing inter-organizational electronic commerce applications." See "Exchangeable Routing Language (XRL)."
"An Experimental Approach Towards the XML Representation of Petri Net Models." By Ousmane Sy, Mathieu Buffo, and Didier Buchs (LIHS-FROGIS, Université Toulouse I, Place Anatole France, F-31042 Toulouse CEDEX, France). "XML has attracted many application developers because it eases the interchange of data between heterogeneous applications. XML based proposal are currently being elaborated to store Petri nets models. The fact that some Petri nets tools already use XML for storage purposes shows that XML may be suitable for Petri nets tools. But it also raises the question of interchange of models between different tools. Indeed, each tool defines its own storage format (DTD - Document Type Definition) using XML, which can make the interchange difficult if the DTD is not standardized. In order to get insights for the definition of standard XML representations, we have set up a research team whose goals are the following: (1) make a survey of the available tools in order to gather information about the various features they support; (2) extract and build a taxonomy of formalisms in order to identify clusters of Petri net dialects that have the same needs; (3) and finally propose a XML representation standard for Petri nets tools derived from this taxonomy. This paper presents the preliminary results derived from our survey and will be completed according to incoming information up to the Petri net conference."
Petri Nets World - "a variety of online services for the international Petri Nets community..."
