DOM

The following table and the figure in it illustrate this. Regardless of the kind of information in your XML document (whether it is tabular data, or a list of items, or just a document), DOM creates a tree of nodes when you create a Document object given the XML document. Thus DOM forces you to use a tree model (just like a Swing Tree Model) to access the information in your XML document. This works out really well because XML is hierarchical in nature. This is why DOM can put all your information in a tree (even if the information is actually tabular or a simple list).

<?xml version="1.0"?>
<addressbook>
<person>
<name>penta</name>
<email>penta@pentafour.com</email>
</person>
</addressbook>
<addressbook>
<person>
<name>soft</name>

<email>soft@pentafour.com</email>

</person>

</addressbook>

Figure is overly simplistic, because in DOM, each element node actually contains a list of other nodes as its children. These children nodes might contain text values or they might be other element nodes. At first glance, it might seem unnecessary to access the value of an element node (e.g.: in "<name> Ponta soft</na me>", Pentasoft is the value) by looking through a list of children nodes inside of it. If each element only had one value then this would truly be unnecessary.

However, elements may contain text data and other elements; this is why you have to do extra work in DOM just to get the value of an element node. Usually when pure data is contained in your XML document, it might be appropriate to " lump" all your data in one String and have DOM return that String as & value of a given element node. This does not work so well if the data stored in your XML document is a document (like a Word or Framemaker document).

In documents, the sequence of elements is very important. For pure data (like a database table) the sequence of elements does not matter. So DOM preserves the sequence of the elements that it reads from XML documents, because it treats everything as it if were a document. Hence the name DOCUMENT object model.

If you plan to use DOM as the Java object model for the information stored in your XML document then you really don't need to worry about SAX. However, if you find that DOM is not a good object model to use for the information stored in your XML document then you might want to take a look at SAX. It is very natural to use SAX in cases where you have to create your own CUSTOM object models. To make matters a little more confusing, you can also create your object model(s) on top of DOM. OOP is a wonderful thing.

Domain Name Search