XML defines a standard way to describe tree like structures. To keep them in memory a standard approach is used: each tree node is an object, with a reference to its parent and a list of children.
All SyncML packages are internally represented in this tree notation. A tree is represented by a pointer to its head node.
To mix XML documents from different sources, the XML specification defines namespaces. The SyncML protocol itself uses three different namespaces: One for the protocol itself, one for device information, and one for meta information. But these are not the only namespaces that can occur in a package: If the data itself is represented in XML, then it might also have its own tags and namespaces.
Internally, however, a tree node type is not represented by the actual string and its namespace. This would be way to expensive for comparison. Therefore internally a numeric representation is used.
The SMLNamespaceContainer takes care of
all this. It maps the numerical representation to its string
representation and vice versa. It has all SyncML namespaces built in
and extends itself for foreign tags and namespaces.
Keeping the tree in memory is nice, but sometimes it has to be
sent out to another device or maybe saved to disc. The
SMLFlattener is responsible for creating an XML
representation of the SyncML package tree. This class can be extended:
The SMLNiceFlattener for example takes care of
formatting the output with line breaks and indention.
Before a response package can be sent out, it has to be built
first. The SMLResponsePacket class handles the
creation of the response packets. It starts out with a reasonable
default that can be changed. It also makes sure that the resulting
packet conforms with the specification. It even handles such things as
the actual sending.
This is an interface class for callback from
SyncMLParser. It is used so that the actual XML
parser can be exchanged, and no other code would have to be changed in
the library.
The SyncMLParser class is an adapter for
an XML parser. It currently uses Libxml
from the gnome project. But it is planned
to also support Xerces (from the
Apache project) in the future.