Overview
Page 1 (8 pages total)
This chapter will study a variety of programming interfaces of XML. These interfaces provide a consistent interface for developers using XML documents. There are many APIs to use; this chapter studys four of the most popular and widely used APIs: Document Object Model (DOM), Simple API for XML (Simple API for XML (SAX)), JDOM and Java API (Java API for XML Parsing (JAX)) for XML parsing. (You can find more information about these APIs through a large number of links in the reference.)
Document object model
A document object model (commonly referred to as a DOM) defines a set of interfaces for the resolution version of the XML document. The parser reads the entire document and builds a tree structure that resides in memory, then your code can use the DOM interface to operate this tree structure. You can traverse the tree to understand what the original document contains, you can delete several parts of the tree, you can rearrange the tree and add new branches, and so on. The DOM is created by W3C and is a formal recommendation for the association.
DOM problem
DOM provides a rich set of features that you can use these features to explain and operate XML documents, but use them. When developing the original DOM for XML documents, many people on the XML-DEV mail list present several issues of the DOM:
Dom builds the entire document resides in memory. If the document is large, it will require great memory. DOM creates objects that represent each thing in the original document, including elements, text, properties, and spaces. If you only need to pay attention to a small part of the original document, create those objects that never use are extremely wasteful. The DOM parser must read the entire document before your code gets control. For very large documents, this will cause significant delays. These are just problems caused by the design of the document object model; how these issues are discarded, the DOM API is a very useful way to analyze the XML document.
Simple API for XML
To solve the DOM problem, XML-DEV participants (leadership by David Megginson) created SAX interfaces. Several features of SAX solve the problem of DOM:
The SAX parser sends an event to your code. When the parser finds the elements, the element is ended, the text, the beginning or end of the document, will tell you. You can decide what event is important to you, and you can decide what type of data structure to create to save data from these events. If you do not explicitly save data from an event, it is discarded. The SAX parser does not create any object at all, it just passes the event to your application. If you want to create an object based on those events, this will be done by you. The SAX parser starts sending events when parsing. When the parser discovers the document, the element starts and text, etc., the code will receive an event. Your app can start generating results immediately; you don't have to wait until the entire document is parsed. Sometimes, if you only find some of the content in the document, once you find what you want to find, you can throw an exception. This exception will stop the SAX parser, then the code does anything it needs to do with the data it finds. It's all said that SAX and DOM have a thousand autumn. Some of this chapter will discuss why you may need to use different interfaces.
SAX problem
Fair, SAX parsers are also aimed at attention:
The SAX event is stateless. When the SAX parser found text in the XML document, it sends an event to your code. This event only gives you the text discovered; it doesn't tell you what element contains that text. If you want to know this, you must write your status management code yourself. SAX events are not lasting. If the application requires a data structure to model the XML document, you must write that code yourself. If you need to access the data from the SAX event, you have to store the data in the code, then you have to resolve the document again. SAX is not controlled by a centralized management. Although this has not yet caused any problems so far, if SAX is controlled by an organization like W3C, some developers will feel more. JDOM
Difficulties when using the DOM and SAX models, make Jason Hunter and Brett McLaughlin feel disappointed, so they created a JDOM package. JDOM is an open source project based on Java technology. It tries to follow 80/20 rules: with DOM and SAX 20% function to meet 80% user needs. JDOM uses SAX and DOM parsers, so it is implemented as a relatively small Java class. The main feature of JDOM is that it greatly reduces the number of codes you must write. Although this introductory tutorial does not discuss programming themes, the length of the JDOM application is usually one-third of the DOM application, approximately half of the SAX application. (Of course, insist on using the pure hiist of DOM recommends: From the long run, learn and use the DOM to return to the return). Jdom doesn't do everything, but for most of the resolution you want to do, it may just fit you.
Java API for XML analysis
Although DOM, SAX and JDOM provide standard interfaces for most common tasks, there are still some things that they cannot solve. For example, the process of creating a Domparser object in a Java program is different due to the DOM parser. To correct this problem, Sun released JAXP (Java API, Java API for XML Parsing) for XML parsing. The API provides a common interface for using the DOM, SAX and XSLT processing XML documents. JAXP provides a standard interface for interfaces such as DocumentBuilderFactory and DocumentBuilder and DocumentBuilder. There are also methods that allow you to control whether the underlying parser can identify namespaces and whether to use DTD or mode to verify the XML document.
Which interface is suitable for you?
To determine which interface is suitable for you, you need to understand the design points of all interfaces, and what you need to understand what the application will do with the XML document you want to process. Considering the following questions will help you find the right way.
