Protocol of the 4th GXL/GTXL-Meeting at the Workshop
on "Graph-Based Tools" in Barcelona
October 8, 2002
Discussion Chair: Andreas Winter
Protocol: Gabriele Taentzer
Status Report on GXL by Andreas Winter
Status Report on GTXL by Gabriele Taentzer
Experiences with GXL/GTXL
Application scenarios for GXL/GTXL
Layout in GXL
Compatibility of XMI and GXL
Status Report on GXL:
During the talk by Andreas some experiences with GXL have been discussed
The type representation in GXL is too complicated and redundant, if
simple labelled or typed graphs are supposed to be stored. In GXL type
graphs or graph schemes have to be referred to by Xlinks. A simpler way
to store node and edge types could be special attributes with name "type".
In both solutions type checking is not supported by the XML technology
which means that standard XML type checking tools cannot be used following
this line. Another idea is to store graph types by different XML tags,
e.g. a node of type "Function" would be stored in an XML tag <Function>.
But here, we give up the idea of having one standard exchange format for
al kinds of graphs, since we would have different DTDs for different type
For the type representation of GXL as it is now a tool is currently under
development in Koblenz which does the checking of a graph according to
its graph schema..
A comparison of GXL with XMI is needed. This topic is shifted to the
Status Report on GTXL:
After the talk
by Gabi several questions arose:
Jürgen Ebert: The connection between GXL and GTXL is not always clear.
How are rule graphs stored?
Adrian Vasiliu asked how far GTXL has been compared with other rule exchange
formats such as RuleML. Not yet.
Hartmut Ehrig asked how far semantic aspects of graph transformation systems
(GTS), i.e. how rules are applied, can be stored in GTXL. Additional attributes
to a GTS can used to store aspects of graph transformation approaches.
This idea has to be further worked out.
Experiences with GXL/GTXL:
GXL: Modelling standards how to present a certain graph structure in GXL
is missing. Application specific standard schemes should be developed to
fix representation decisions in GXL. Current work in reverse engineering
deals with the definition of reference schemes e.g. for representing C++
sources on SAT level and for representing sources language independent
on a middle level.
The integration of GAL and GTXL has to be reconsidered again. Concrete
change requests for GTXL:
A number of tags defined in GTXL such as rule, mapping, ruleGraph, graphCondition,
have attributes "id" and "name". Mostly, only one of them is needed.
The notation for rule mappings can be considerably shortened for injective
mappings. In this case, a rule can be represented by denoting three
parts, a graph which is preserved, and two graph parts, one to be deleted
and one to be created. This approach follows the collaboration style to
describe a rule. Since, rules are usually injective, this kind of shortcut
notation is worthwhile to be available in parallel to the current rule
notation by left and right-hand side graphs together with a mapping from
left to right.
Further attributes for graph transformation systems are needed to fix a
certain transformation approach, e.g. a rule shall always be matched injectively.
Michel Bauderon: There is another XML-based format for graphs in the new
quasi ISO norm MPEG7 which should be compared with GXL.
Gabriele Taentzer, Andy Schürr: Storing of attributes in GXL: There
is still not a clear opinion whether the fixing of basic attribute types
like string, seq, and set in GXL should be kept. Complex attributes like
arbitrary Java objects and multi media documents are supposed to be stored
in separate documents and referred to by Xlinks.
Andreas Winter reported that Susan Sim is in contact with the
IEEE to get GXL become a standard format.
Application Scenarios for GTXL:
came up with a possible application scenario for GTXL such as
Andre Marburger: Hot plugging of graph rules in GTXL format to get better
Tom Mens: Exchange of software metrics in GTXL format between different
Albert Zündorf: Provision of front-end visual editors for graph transformation
systems which export to GTXL
Daniel Varro: Model checking graph transformation systems: The input format
for model checkers would be GTXL.
Jan-Hendrik Hausmann: A front-end editor stores graph transformation systems
in GTXL. A graph transformation engine can read it in.
Michael Lawley: A graph transformation engine which understands GTXL input
In the end, Andy Schürr pointed out that exchanging batch files
in XML format is a first step which should be followed by possibilities
for iterated exchange of updates.
Using GXL and
SVG for Describing Graphs with Layout, talk by Mark Minas,
short version held by Andy Schürr
Andreas Winter pointed out that XPath might help to navigate to a GXL element
without id, since Xlinks cannot be used in this case.
Adrian Vasiliu explained how the layout is computed in JViews. Graphs
and their layout are stored separately. CSS is used to define a rendering
for a graph stored in some XML format.
Daniel Varro pointed to his approach presented in his talk at GraBaTs on
"An Open Visualization Framework for Metamodel-Based
Compatability of GXL and XMI:
Both formats are quite compatible with each other. XMI does not yet support
hyperedges and association inheritance. GXL contains several shortcuts
compared with XMI.
Time and place for the next discussion on GXL/GTXL are not yet fixed.