The object-to-XML mapping is rather straightforward. UML attributes and roles names are rendered respectively as XML attributes and XML sub-elements with the same name in XML. The Item attribute documentation is rendered as a sub-element, in order to preserve text presentation.
The object-model distinguishes two kind of associations: aggregations and simple associations. Aggregations are rendered as XML as sub-elements. Simple associations are rendered as sub-elements containing the target item references (the ItemRef object), named with the association's target role.
Every rule has its exception so here is one: parent-child relationships are rather generic because they are modeled on the Item class. The roles parent and children are not rendered using the generic rules.
Children is rendered with the lowercase name of the child class: for instance package for the package's of a model and class for the classes of a package. Parent association is not rendered, with the exception for packages, see below.
Any UML document is enclosed in a model top-level element, introducing the reserved namespace's URI:
<!-- model sub-elements -->
The model in turn contain packages. Packages are not rendered in a full-hierarchical structure, each package containing its children packages: this is because the resulting XML document would both be complex to render and parse, and also the number nested sub-elements would become huge. So packages are all rendered as model children. They include a reference to their package parent.
A small example is better than a long speech, so here is one:
<?xml version="1.0" encoding="ISO-8859-1"?>
<ug:documentation>A UML class.
Can be a child of a package, or embeded inside another class.
An interface is just a class with the stereotype "interface".</ug:documentation>
<ug:documentation>An abstract class cannot have instance.</ug:documentation>