Protocol of the 4th GXL/GTXL-Meeting at the Workshop on "Graph-Based Tools" in Barcelona

Discussion Chair: Andreas Winter
Protocol: Gabriele Taentzer

Agenda:

1. Status Report on GXL by Andreas Winter
2. Status Report on GTXL by Gabriele Taentzer
3. Discussion Topics:
1. Experiences with GXL/GTXL
2. Application scenarios for GXL/GTXL
3. Layout in GXL
4. Compatibility of XMI and GXL

• Status Report on GXL:
During the talk by Andreas some experiences with GXL have been discussed immediately:
• 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 graphs.
• 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 later discussion.
• 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:

          Several people came up with a possible application scenario for GTXL such as
• Andre Marburger: Hot plugging of graph rules in GTXL format to get better re-engineering tools
• Tom Mens: Exchange of software metrics in GTXL format between different metrics tools
• 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 is desirable.

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 Modeling Languages"
• 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.