The iXML library is an implementation of three core XML services:

The XML parser's task is to take an XML document - which is basically a chunk of text data - analyze it for syntactical correctness and create an in-memory representation of the data and the data's structure.

The application calling the parser can get access to this in-memory representation in two ways:

a) as "events", which means that the parser passes control back to the calling application whenever the next piece of information has been parsed from the XML document (e.g. here's a new element, here's a new attribute etc.).

b) as "DOM" tree, which means that the parser creates a tree of object instances in memory. The tree is reflecting the structure of the XML document and the tree nodes - the object instances - represent the logical elements and their data in the document. The DOM (Document Object Model) defines interfaces to traverse, query and modify the tree and therefore the underlying XML document.

As mentioned before the DOM - or Document Object Model - is a definition of classes and interfaces that represent the structure and content of an XML document. For each logical construct in an XML document there is corresponding class or interface in the DOM. Here's an example: elements are represented as objects of the Element class, attributes of elements are represented as objects of the Attribute class, the text data of an XML document is represented as objects of the Text class etc.. As you can see, so far everything is straightforward.

Representing the structure and content of an XML document as DOM classes and interfaces has one big advantage over working solely on the bytestream of the XML document: You don't have to do the low-level parsing stuff yourself and you can use the DOM classes and interfaces in your program as you would use any other class or function library. Furthermore, once you understand and know the interfaces, you'll find the same infrastructure in place in a lot of other environments and programming languages: Internet Explorer 5.0 provides a DOM for XML documents when using client-side scripting in DHTML, or there are several public-domain Java implementations of the DOM. They all share the same basic classes, interfaces and concepts. So once you know one of them, you'll know them all.

Once you have a DOM representation of an XML document, you can modify it in any way that crosses your mind: add new data, change existing data, remove data, query data and a lot more.

Usually you won't just be happy with the services mentioned so far if you want to not only import XML documents or data, but also export the like. You can of course create an XML document by simply writing the appropriate bytes into a bytestream yourself, but once you have realized that there are some nasty details about the XML representation in bytestreams (e.g. UTF-8/UTF-16 encodings, escaping of special characters etc.), you might want to delegate this task to somebody else. The one you should pick is the XML renderer - some call it "builder" because it builds XML documents. Don't confuse the XML renderer with your browser. The renderer does not render the XML document in terms of visual display or layouting. The renderer "renders" the in-memory representation of an XML document or data into a bytestream. Starting point is a DOM representation of an XML document which can be either created by parsing an already existing document into a DOM representation or by creating a DOM tree from scratch using the DOM interfaces.