A Simple XML Exchange Format for Graph Transformation

Gabriel Valiente

Motivation

The need for a common exchange format for graph transformation based on
XML has been a major conclusion of the panel on the perspectives of graph
transformation that took place during the Joint APPLIGRAPH and GETGRATS
Workshop on Graph Transformation Systems, held in Berlin in March 2000.

Design Goal

Previous proposals evolved from the attempt to store a program for a
particular
graph transformation system in XML format. While the Berlin Proposal
is based on AGG, the Kent Proposal is based on Grrr, and the
Koblenz
Proposal has a clear PROGRES flavor.

The main design goal of the present Barcelona Proposal is
simplicity.
As will (hopefully) become clear from the discussion below, taking, say,
the minimum common XML data supermodel for all existing graph
transformation
systems and taking also future graph transformation systems (will ever
GRACE get incarnation) as well as future uses into account, is perhaps
too ambitious a goal to be reached in the short or mid term. The maximum
common XML data submodel for all existing graph transformation
systems
could be adopted instead, agreeing upon those features (elements and
attributes)
considered to be essential and leaving out additional features which,
although
important for particular applications, are not essential from the point
of view of software exchange within the graph transformation community.

The XML Data Model

The XML data model proposed as exchange format for graph transformation
is described in the sequel in a literate programming style, combining code
and documentation.

In its simplest form, a graph transformation system consists of zero
or more graphs followed by zero or more graph transformation rules.

<!ELEMENT gts (graph*, rule*)>

A graph has an optional identifier and consists of a sequence of nodes
followed by a sequence of edges.

A graph transformation rule has an optional identifier and consists
of a left-hand side graph, a right-hand side graph, and a map of the former
into the latter.

<!ELEMENT rule (lhs, rhs, map)><!ATTLIST rule id
ID #IMPLIED>

<!ELEMENT lhs (graph)>

<!ELEMENT rhs (graph)>

A map (representing a graph morphism) consists of a sequence of node
correspondences followed by a sequence of edge correspondences. Notice
that the latter is needed because it cannot always be obtained from the
former in a unique way, for instance when dealing with multigraphs or when
the notion of subgraph underlying the graph transformation approach is
not that of induced subgraph.

It makes a multigraph simple by removing parallel edges. Okay, under
a particular approach to graph transformation and under certain application
conditions, but in the realm of XML (only | mostly) syntax is dealt with.

Open Questions

Hypergraphs

Should only multigraphs be encompassed by the XML data model, or also
hypergraphs,
relations, algebras, ...? The Berlin Proposal covers the CS notion
of a hypergraph by a simple extension, namely replacing

Layout

Regarding layout of graphs, the essential information should include at
least the coordinates of the center of each node in a certain coordinate
system. Now, further information to be associated to the nodes and edges
is restricted only by imagination. For the sake of comparison, the
additional
information used in LEDA could be encoded as follows:

A general XML data model covering all the features used for representing
graphs and graph transformation rules in ( all | most ) existing graph
drawing and graph transformation tools, as well as in other applications
where graphs are used, seems too ambitious a goal to be reached in the
short or mid term. A more pragmatic stance is needed, perhaps agreeing
upon a reasonable subset of additional information that could be exchanged.

The solution adopted in the Koblenz Proposal is twofold. On the
one hand, any number of attributes may be defined for a node or an edge:

The same use of attributes is found in the Berlin Proposal and
also in the Kent Proposal, in which an attribute is allowed to link
to a sequence of further attributes, something that does not seem to be
necessary given that always sequences of attributes are used.

On the other hand, in the Koblenz Proposal the use of graph
schemata
is advocated, although the same structural information could be represented
by an extended notion of typing.

Typing

The notion of type underlying the Koblenz Proposal could be encoded
by an optional string attribute of nodes and edges: