step 1: The Prolog and the Root
Element 
From Graph to Schema
As some GXL schema code will be introduced in the following, it would be interesting to see how the class diagrams of the GXL schema look like, compared to the object diagrams of the GXL graph, and how the GXL schema is represented by a GXL graph, which is shown as an UML object diagram. For constructing the class diagrams, the object diagrams of gxl/gxl-graphs will be used here; the GXL code of the matching graphs (shown in the diagrams at the righthand side) will be formed in gxl/gxl-schemata.
It should be clear, how to build the corresponding class diagram (the jump from the left to the middle column), but while transforming these class diagrams to the representing object diagrams (the jump from the middle to the right column), the rules and restrictions of the graph classes have to be followed, which the GXL Meta Schema defines - the overview of the format in gxl/the_basics would be interesting for further information here. The transformation is based on the GXL Meta Schema in version 1.00 Beta, but the changes to the final version will be inconsiderable. Furthermore, it has to be mentioned that the IDs are left out in the following graphs, because they are arbitrary.
Note: The arrows below are links to the corresponding steps in gxl/gxl_graphs (left arrow) and gxl/gxl_schemata (right arrow).
step 1: The Prolog and the Root
Element
In the first step, there is no diagram to transform.
As it can be seen, the step from the object to the class diagram is only visible in a loss of the instance names. A look at the right column shows, that the three graphs are derived from the Meta Schemas GraphClass, which is visible in the typification of the three graph nodes. The names of the graph classes are saved as string attributes.
In the same way as above, the step from the object to the class diagram is only visible in a loss of the instance names. A look at the right column shows, that the two elements are derived from the Meta Schemas NodeClass, which is visible in the typification of the two nodes - the names of the node classes are saved as string attributes, too. Not to forget is the unnamed graph node, which contains the two nodes and is part of all following schema-graphs (therefore it will not be mentioned any further).
These graphs visualize how attributes are handled. The jump to the middle should be clear, because only the values are lost, but the right graph needs further explanation. As it is defined in the MetaSchema, attributes are derived from the AttributeClass (again with the names as string attributes inside) and are linked to the suitable NodeClass by a directed edge (typed as hasAttribute).
The attributes type of value is fixed by an edge connection (here a directed edge, typed as hasDefaultValue) to the matching "value node" (typed as BoolVal, FloatVal, IntVal, etc. - corresponding to the type of the attribute). If the attribute is of composite type, the corresponding "value node" is connected to the node of the contained value type by a composite association.
As the nodes loose their instance names in the class diagram, also the edge names are not shown any more. The rest is transformed in the same way as described above.The upper graph shows how edges are realized in the representing graph in the right column. It can be seen that the edges are derived from nodes, typed EdgeClass, carrying the name of the edge as a string attribute. Additional to that, they carry the bool attribute isDirected, which has the information, whether it is directed or not. It is connected to its origin and destination by directed edges typed from and to.
step 6: Ordering of Incidences
The only new information in this step is the realization of the ordering in the different stages. Of course, with the jump to the middle we loose the concrete ordering information - we only have to know here, if the edge end is ordered, or not, which is stored by the property {ordered} (it has to be mentioned here, that there is at the moment no possibility for storing this information). In the right column this information is stored as an attributed called isOrdered in the adequate from- or to-typed edge.
The relation itself is handled like an edge, it looses its instance name in the step to the class diagram and is realized as a node, typed RelationClass (carrying the name of the class as a string attribute) in the correspondings schema graph. But the transformation of the relation ends is managed in a different way; they do not loose their roles in the class diagram and are realized as nodes, typed RelationEndClass, which are carrying as attributes, in which direction the relation end is directed (directedTo) and whether the relation end is ordered at the relation, or not (isOrderedRelation).
The relation end nodes are connected to the suitable "relation node" by a directed aggregation, typed hasRelationEnd and to the targeted node by a directed edge, typed relatesTo, which contains the role as an attribute (named role).
A conversion of hierarchical graphs will follow in this step. Due to the ongoing discussion about their implementation in GXL it is not possible at the moment to transform them to schemata here.