Transform XML Documents with AGG

Gabriele Taentzer, Giovanni Toffetti Carughi

1 Summary

This example shows how to use a graph grammar to specify the transformation from an XML document representing a UML Class Diagram into another XML document representing an Entity-Relationship model in WebML.

We argue that the approach we propose it's simpler than specifying a transformation in XSLT as the developer has the chance to design the transformation visually, abstracting from document structure and element production order. In addition to this, in some cases the Graph Grammar transformation (from document type A to B) can be automatically reversed to produce the inverse transformation (i.e. form document type B to A).

2 Relation between XML Documents and AGG Graphs

To be able to use graph transformation for XML documents, there must be translations between XML documents and graphs. A simple solution is to provide universal XSL transformations from XML documents (without DTD or XMLSchema) to AGG graphs in the proprietary XML format for AGG, GGX, and back from GGX to XML. Once provided the user can completely concentrate on graph transformation and does not have to deal with XSL transformations at all. This idea can be extended to XML documents which conform to a DTD or XML Schema. In this case, the universal XSL transformation also transforms the DTD or XML Schema into a corresponding type graph. In this case the type graph may be enhanced by stronger constraints such as multiplicities. These XSL transformations are applicable to any XML documents.

As an example, consider the following XML snippet:

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE WebML
SYSTEM"WebML.dtd">
 <WebML xmlns:auxiliary="http://www.webml.org/auxiliary"
       xmlns:graphmetadata="http://www.webml.org/graphmetadata"
       xmlns:presentation="http://www.webml.org/presentation"
       siteName="Acme" version="3.0.18">
  <Structure graphmetadata:go="Structure_go" id="Structure">
    <ENTITY auxiliary:testCaseCount="20"
        graphmetadata:go="User_go" id="User" name="User">
        <ATTRIBUTE id="userName" name="UserName" type="String"/>
        <ATTRIBUTE id="password" name="Password" type="Password"/>
        <ATTRIBUTE id="email" name="EMail" type="String"/>
        <RELATIONSHIP id="User2Group" inverse="Group2User" maxCard="N"
         minCard="1" name="User_Group" roleName="User2Group" to="Group"/>
         <RELATIONSHIP id="User2DefaultGroup" inverse="DefaultGroup2User"
         maxCard="1" minCard="1" name="User_DefaultGroup"
          roleName="User2DefaultGroup" to="Group"/>
     </ENTITY>
        ...
  </Structure>
</WebML>

The following figure shows the structure of the corresponding AGG graph resembling a DOM tree.

Figure 1: Graph which represents the example WebML document

The translation from an XML document instance to a GGX graph can be obtained for example with this stylesheet. Once a source graph has been transformed into a target graph via a graph grammar, a graph-to-XML stylesheet like this one can be used to obtain the result XML document.

3 The common Type Graph

The source and target documents are visualized by graphs as discussed above. Just as in XSLT a transformation is defined on a document structure instead of on a document instance, an XML transformation can be precisely defined by a graph transformation system GTS = (T, R) consisting of a type graph T and a set of transformation rules R. The structure graphs of the source documents can be specified by a subset of instance graphs over a type graph T_S. Correspondingly, the structure graphs of the target documents are specified by a subset of instance graphs over a type graph T_T. Both type graphs T_S and T_T have to be subgraphs of the common type graph T. Starting the XML transformation with instance graph G_S typed over T_S, it is also typed over T. During the transformation process, the intermediate graphs are typed over T. Please note that this type graph may contain not only T_S and T_T, but also additional types and relations which are needed for the transformation process only. The result graph G_T is automatically typed over T. If it is also typed over T_T, it fulfills the requirement to be valid.

The common type graph T for our transformation is shown below. Source document nodes are depicted in red with pink edges to represent possible nesting (XPATH child axis), target document nodes are represented in black with blue edges for nesting. The type graph below also uses generalization/specialization hierarchies: any red node inherits attributes (position and text) as well as edges from the red "XMLNode" node. The same happens for target document nodes. Thus, we represent that in the rules we will use a "transf" node to connect any source element with its translation in the target document by means of a "transf" node with directed edges to the topmost element of the document nodes ISA hierarchy.

Figure 2: Type graph for the transformation

4 The rules

The graph grammar is composed by the 6 simple rules that follow. For each rule we only show the LHS and RHS, but each rule also has a negative application condition equal tho the RHS, preventing its application more than once for the same elements.

4.1 Root rule

Figure 3: Root rule of the transformation

The above rule transforms the root of the XMI Class Diagram into the root node of a WebML project document. No attribute values are copied. The transformation node and edges connect each element with its translation.

4.2 Model to Structure rule

Figure 4: Rule transforming a model subtree into a structure node

The above rule transforms a ÜML:Model" node and some of its sub-elements into a "Structure" node. This rule matches only after the root rule has been successfully applied. In fact, the LHS contains a "WebML" node that will be used in the RHS as the XML parent node of the newly created "Structure" element. Here we see that the "xml.id" attribute of the ÜML:Model" is also used as the new Structure nod ïd" attribute.

4.3 Class to Entity rule

Figure 5: Rule translating a UML class into a WebML ER-entity

The same thing happens here with classes and entities. We use a previously created translation node to keep track of where exactly in the target document we want to place the newly created node. This time we copy more attributes.

4.4 Association to Relationship rule

Figure 6: Rule transforming an association subtree into two non-sibling relationship nodes

The above rule is used to create two relationship nodes starting from a UML:Association subtree. In LHS, we search for a pattern consisting of an association with association ends which refer to the participating classes by attribute participant in UML:AssociationEnd nodes. The references are enforced by variables part1 and part2, to be matched with class IDs. Please note that this rule inserts two relationships, i.e. translates the association completely in one step, something not achievable in XSLT. Moreover, the use of variables to resolve IDREFs makes the rule clear at first sight. Again, this rule has a negative application condition structurally equal to the RHS, which prevents the rule from being applied twice to the same association.

4.5 Classifier Features

Figure 7: Rule connecting an Entity with its features

The above rule is a work-around to allow attribute translation by the attribute rule. In the somehow verbose XMI schema, UML:Class nodes have a child UML:Classifier.feature node only when they represent classes with at least some feature (e.g. attributes). Thus, attributes are not direct siblings of a UML:Class node, but they are connected to an intermediate node. Therefore, in order to provide the correct placement of attribute nodes into the target document, we need to keep track of the UML:Classifier.feature node.

4.6 Class Attribute to Entity Attribute

Figure 8: Rule translating an attribute subtree into an attribute node

Once we know which feature list belongs to which target document Entity element, we can copy the attribute values we need into the newly created Atribute node.

5 Rule inversion

An inverse grammar (from WebML-ER to XMI class diagrams), can be obtained automatically inverting each rule.

File translated from T_EX by T_TH, version 3.72.
On 23 Mar 2006, 16:50.