Information content and processing strategies
Prev Chapter 2. Basics of XML Next

Information content and processing strategies

A well-formatted XML document seems to be only a set of characters, but if you try to learn the obtainable information, it is more valuable than at first look. To this end, the W3C created a recommendation, named InfoSet, which defined the abstract dataset to describe the well- formatted XML documents’ abstract information content.

An XML document has InfoSet, if:

Basically, this is built up from information elements, which is the abstract description of the XML documents’ parts, which has named properties. It always contains at least one element, “document”, which is the root element. There are eleven different information elements; you can see the most important ones below:

From the example of the W3C's website we can easily understood how to imagine that abstract information set.

<?xml version="1.0"?>
<msg:message doc:date="19990421"
     xmlns:doc="http://doc.example.org/namespaces/doc"
     xmlns:msg="http://message.example.org/">Phone home!</msg:message>

This XML document has the following InfoSet:

After all it is important to note what are NOT in the Infoset:

This overview is an important piece of information about the Infoset because this is the base of the different parsing strategies. The most important implementations are inside the DOM and XPath data model. However, before reaching them we need to note that there are an extended version of the Infoset which could be obtained during the validation. The process itself is called InfoSet Augmentation, and the produced output (the augmented InfoSet) document is called Post-Schema-Validated InfoSet (PSVI). It is important to highlight again that it produced during the validation and ONLY XML Schema could be used for it.

Language independent processing strategies: DOM and SAX

The Document Object Model (DOM) is a platform- and language independent standard application programming interface which models the HTML, XHTML, XML and other, closely related formats' structure and their interaction with their objects. The DOM is a system of objects that are related through a parent-child relationship. It contains the document’s content, as well as every other part of the document, and changes here will also change the appearance of the page in the browser.

It’s creation was motivated by the browser war that happened during the years of 1990, which eventually get concluded by the born of the W3C standardization processes. After the first draft of DOM appeared in 1998, two more appeared in 2000 and 2004. Currently the 2004 recommendation is used, since 2012, version 4 is being created. It’s also worth mentioning that server-side interface events was still not a recommendation in 2012, but it is still very close to it.

DOM architecture can be visualized according to this chart:

Figure 2.1. DOM architecture


The DOM most important specifics:

  • -the document is logically managed as a tree (Node object hierarchy)

  • -object model in the sense of the classical OO

    • documents (and it’s other parts) are objects with identity, structure, behavior, and relations

  • the DOM API provides two possibilities:

    • inheritance-based OO approach

    • a simple (flattened) view („everything is a Node”)

  • Suitable for:

    • creating, building documents

    • structurally go through documents

    • element and content adding, modifying, deleting in documents.

  • It’s built up from modules (DOM Core is blue, XML DOM is yellow).

    Figure 2.2. DOM modules

    DOM modules


The usage of DOM looks like the following figure:

The Simple API for XML (SAX) is an event-driven interpreter, which means that it doesn’t create a representational model, like the DOM, that can be traversed in any way, rather the document processing is linear, similar to reading a text. The document is treated as a stream, during the interpreting, reaching certain points activates the corresponding event, to which the programmer can answer through implementing the API functions. SAX is not managed by the W3C, rather the Java language version is always the most up-to-date.

The usage of SAX looks like the following figure:

Compared to the DOM, an XML document does not have classes used for representation, instead the interpreter uses an interface, through which programs can access the data in the processed document with function calls. It consists of 4 basic types:

  • string nodes

  • element nodes

  • processing instructions

  • comments.

This provides a very fast and memory-efficient method for the SAX interpreter, because it requires significantly less memory compared to the earlier mentioned DOM interpreter. The biggest disadvantage is that its usage requires complex design and implementation, because we don’t have already defined tools, through which we could easily represent and store the document’s necessary and required parts. These must be designed and implemented by the developer.

The usage of the SAX API is recommended when we want to process large XML documents. In this case, we need less space during the interpreting itself, also local file usage is much more likely to be faster compared to the DOM API. If we want to use inner references or we need to access the document elements randomly, as such we’re using almost the whole document, it’s better not to use the SAX API because of it’s complexity.

DOM and SAX quick review:

  • DOM

    • tree based model (data is in nodes)

    • quick access

    • possibility for node adding/deleting

  • SAX

    • methods called when reaching markup

    • better performance

    • less memory usage

    • suited for reading through the document, not modifying it.

Prev Up Next
Valid XML documents  Home The fundamentals of document design