Why do they exist at the same time?
--------------------------------------------------------------------------------
SAX (Simple API for XML) and Dom (Document Object Model) are designed to allow programmers to access their information without having to write a parser. By saving information in XML 1.0 format and using sax or DOM APIs, your program can use any parser. This is because developers who use their favorite language to develop the parser must implement Sax and Dom APIs. Sax and Dom APIs can be implemented in multiple languages (Java, C ++, Perl, Python, other ...).
So both Sax and Dom exist for the same purpose, which enables users to access the information stored in XML documents using any programming language (there must be a parser of that programming language ). Although they provide different methods to access your information.
What is Dom?
--------------------------------------------------------------------------------
Dom allows you to use hierarchical object models to access information stored in XML documents. Dom generates a node tree (based on the structure and information of XML documents). You can use this tree to access your information. The text information in the XML document is transformed into a node of a group of trees. See:
Regardless of the type of information in your XML document (whether it is table data, an items column, or a document), Dom creates a node tree when you create a document object in the XML document. Dom forces you to use a tree model (like swing treemodel) to access information in your XML document. This mode is really good Because XML is originally hierarchical. That's why Dom puts your information in a tree (even if the information is in a table or a simple list ???? I don't know how to translate the original text here: even if the information is actually tabular or a simple list ??????).
It is too simple, because in Dom, every element node actually has a series of other nodes as its child. These child nodes can contain text values or other element nodes. At first glance, it is unnecessary to access the value of a child node that accesses an element through traversal (for example: node "<Name> nazmul </Name> ", nazmul is a value ). If each element has only a value, this is indeed unnecessary. However, an element may contain text data or other elements. This is why you need to do additional work in the Dom to obtain the Element Node value. Generally, when your document only contains pure data, it is appropriate to compress all data into a "Block" in the string and let the DOM treat that string as the value of a specific element node. This method is not suitable if the data in your XML document is a document (such as a Word document or framemaker document), the order of elements in the document is very important. It does not matter the order of pure data (like a database table) elements. The reason why Dom keeps the order of Elements read from XML documents is that it treats everything as a document. This document calls the image model accordingly.
If you plan to use dom as a Java object model for your information stored in XML documents, you do not need to consider sax. However, if you find that Dom is not a good object mode that can be used to process XML document information, you may want to see it. In some cases where a custom object model must be used, it is very common to use SAX. To make things seem confused, you can also create your own Object Mode Based on Dom. Object-oriented is really a good thing.
What is sax?
--------------------------------------------------------------------------------
Sax allows you to access the information stored in XML documents, instead of using the node tree, but a series of events. You will ask, what are the benefits? The answer is: select not to create a Java object model on the XML document (as the dom does ). This makes sax faster and makes it necessary as described below:
Create your own custom image model
Create a class that listens to the sax event and create your own object model.
Note that these steps are unnecessary for Dom, Because Dom has already created an object model for you (representing your information with a node tree ).
When Dom is used, the parser does most of the work, reads the XML document, and creates a Java object model based on this, then you will be given a reference to this object (a Document Object), so you can use it. There is no reason why Sax is called Simple API for XML. It is really simple. Sax does not expect the parser to do so much work. All of the sax requirements are that the parser should read the XML document and issue a series of events based on the tags of the encountered XML document. You need to write an XML document processor class (XML document handler class) to handle these events. This means that all tag events are meaningful and you can create objects using your own object model. So you have to finish:
The custom object model that controls all XML document information (or the source document has never been written here, or the source document is suspected to have a typographical error here. This is the case first)
A document processor that listens to sax events (events are generated when the SAX Parser reads your XML documents) and explains these events to create objects in your custom object model.
If your object model is simple, sax runs very quickly. In this case, it is faster than Dom because it ignores the process of creating a tree object model for your information. On the other hand, you must write a sax document processor to explain all the sax events (this is a very heavy job ).
What types of sax events are thrown by the SAX Parser? These events are actually very simple. Sax throws an event for each start tag, as well as for each end tag. It also throws an event for the # pcdata and CDATA sections. Your document processor (listener for these events) needs to interpret these events and create your custom object model based on them. Your document processor must explain these events, and the order in which these events occur is very important. Sax also throws an event for processing instructions, dtds, and comments. however, they are conceptually the same. Your parser should explain these events (and the order in which these events occur) and make them meaningful.
When to use dom
--------------------------------------------------------------------------------
If your XML document contains document data (for example, framemaker documents stored in XML format), Dom is the most natural choice for your solution. If you want to create a system similar to document information management, You have to process a large amount of document data. Datachannel Rio is an example of indexing and organizing information in various types of document resources (such as Word and Excel files ). In this case, Dom is a very suitable program to access the information stored in these documents.
However, if you are mainly dealing with structured data (the serialized Java object in XML the equivalent of serialized Java objects in XML), Dom is not the best choice. That is what is appropriate for Sax.
When to use SAX
--------------------------------------------------------------------------------
If the information in your XML document is machine-readable (and machine-generated) data, Sax is a suitable API for you to access this information. Machine Readable and generated data types include the following:
Java object attributes saved in XML format
Queries expressed by text-based Query statements (SQL, xql, oql)
Result set generated by the query (this may contain data encoded into XML in the relational database table ).
In this case, the data generated by the machine is the data structure and class information that you generally need to generate in Java. A simple example is the address book containing personal information, as shown in. Unlike the word processor document, the XML file in this address book is an XML file that contains pure data that has been encoded into text.
When your data is in this style, you need to create your own data structures and classes (object models) to manage and continuously Save the data. Sax allows you to quickly create a processor class that can generate your object model instance. One example is a sax document processor. It reads XML documents containing the address book information and creates an addressbook class that can access the information. The sax guide tells you how to do this. This address book XML file contains the person element, and the person element contains the name and email elements. My addressbook object model includes the following classes:
Addressbook class, the person object container
Person class, string-type name and email container
In this way, my "Sax Address Book document processor" can convert the person element into the person object, and then store them into the addressbook object. This document processor converts the name and email elements into string objects.
Conclusion
--------------------------------------------------------------------------------
The sax document processor you wrote is used to map elements into objects. If your information is structured to easily create such mappings, you should use the sax API. On the other hand, if your data is more suitable for Tree Representation, you should use Dom.