Omar RABI XML &Data Management
Total Page：16
File Type：pdf, Size：1020Kb
Omar RABI XML &Data Management 011A735777 Presentation Handout
XML DOM and SAX parsers
I. Introduction to Parsers
1. What is a parser?
2. Validating vs. Non-validating parsers
3. Event-based vs. Tree-based parsers
II. The DOM Parser
1. What is DOM?
2. DOM levels
1.1 DOM level 0 1.2 DOM level 1 1.3 DOM level 2 1.4 DOM level 3
3. An Application of DOM
III. The SAX Parser
1. History of SAX
2. Why SAX?
3. SAX API
1.1 SAX parser 1.2 SAX Event Handler
4. An Application of SAX
IV. Conclusion I. Introduction to parsers
1. What is a parser?
The word parser comes from compilers. In a compiler, a parser is the module that reads and interprets the programming language. In XML, a parser is a software component that sits between the application and the XML files. It reads a text-formatted XML file or stream and converts it to a document to be manipulated by the application. Actually there are numbers of parsers such as: validating vs. non-validating and event-based parsers vs. tree-based parsers.
2. Validating vs. Non-validating parsers
XML documents can be either well-formed or valid. Well-formed documents respect the syntactic rules. Valid documents not only respect the syntactic rules but also conform to a structure as described in a DTD. Likewise, there are validating and non-validating parsers. Both parsers enforce syntactic rules but only validating parsers know how to validate documents against their DTDs. Non-validating parsers can read valid documents but won’t validate them.
3. Event-based vs. Tree-based parsers
Tree-based APIs These map an XML document into an internal tree structure, and then allow an application to navigate that tree. Tree-based APIs are ideal for applications that manipulate XML documents such as browsers, editors, XSL processors, and so on. The Document Object Model (DOM) working group at the World-Wide Web Consortium (W3C) maintains a recommended tree-based API for XML and HTML documents, and there are many such APIs from other sources.
Event-based APIs An event-based API, on the other hand, reports parsing events (such as the start and end of elements) directly to the application through callbacks, and does not usually build an internal tree. The application implements handlers to deal with the different events, much like handling events in a graphical user interface. Event-based interfaces are geared toward applications that maintain their own data structure in a non-XML format. For example, event-based interfaces are well adapted to applications that import XML documents in databases. SAX is the best known example of such an API.
Tree-based APIs are useful for a wide range of applications, but they normally put a great strain on system resources, especially if the document is large. Furthermore, many applications need to build their own strongly typed data structures rather than using a generic tree corresponding to an XML document. In both of those cases, an event-based API provides a simpler, lower-level access to an XML document: you can parse documents much larger than your available system memory, and you can construct your own data structures using your callback event handlers.
II. The DOM parser
1. What is DOM?
The Document Object Model (DOM) is an application programming interface (API) for HTML and XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated.
Properties of DOM:
With the DOM, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model.
As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The DOM is designed to be used with any programming language.
structural isomorphism: if any two Document Object Model implementations are used to create a representation of the same document, they will create the same structure model, with precisely the same objects and relationships.
As an object model, the DOM identifies the following:
The interfaces and objects used to represent and manipulate a document.
The semantics of these interfaces and objects - including both behavior and attributes.
The relationships and collaborations among these interfaces and objects.
What DOM is not:
The Document Object Model is not a binary specification. DOM programs written in the same language will be source code compatible across platforms, but the DOM does not define any form of binary interoperability.
The Document Object Model is not a way of persisting objects to XML or HTML. Instead of specifying how objects may be represented in XML, the DOM specifies how XML and HTML documents are represented as objects, so that they may be used in object oriented programs. The Document Object Model does not define "the true inner semantics" of XML or HTML. The semantics of those languages are defined by W3C Recommendations for these languages. The DOM is a programming model designed to respect these semantics. The DOM does not have any ramifications for the way you write XML and HTML documents; any document that can be written in these languages can be represented in the DOM.
The Document Object Model is not a set of data structures, it is an object model that specifies interfaces. Although this document contains diagrams showing parent/child relationships, these are logical relationships defined by the programming interfaces, not representations of any particular internal data structures.
The Document Object Model, despite its name, is not a competitor to the Component Object Model (COM). COM, like CORBA, is a language independent way to specify interfaces and objects; the DOM is a set of interfaces and objects designed for managing HTML and XML documents. The DOM may be implemented using language- independent systems like COM or CORBA; it may also be implemented using language- specific bindings like the Java.
Let’s now examine the following example to illustrate how this kind of parsers will process an xml document:
The DOM parser will then read this document and gradually build up a tree of objects that matches the document. 2. DOM Levels
2.1 DOM Level 0
The HTML DOM is sometimes referred to as DOM Level 0 but has been imported into DOM Level 1. DOM Level 0 is a mix of Netscape Navigator 3.0 and MS Internet Explorer 3.0 document functionalities.
2.2 DOM Level 1
DOM Level 1 concentrates on the actual core, HTML and XML document modes. It contains functionality for document navigation and manipulation. The DOM Level 1 is a set of the most basic functions, i.e. functions for creating, deleting and changing elements and their attributes. The methods of the DOM Level 1 work for both XML and HTML.
Still, the DOM Level 1 specification is intentionally limited to these methods that are needed to represent and manipulate document structure and content. The plan is for future Levels of the DOM specification to provide:
1. A structure model for the internal subset and the external subset. 2. Validation against a schema. 3. Control for rendering documents via style sheets. 4. Access control. 5. Thread-safety. 6. Events.
2.3 DOM Level 2
DOM Level 2 includes the following: A style sheet object model and defines functionality for manipulating the style information attached to a document. Enables of the traversal on the document. Defines an event model. Provides support for XML namespaces.
2.4 DOM Level 3
DOM Level 3 will address document loading and saving as well as content models (such as DTD’s and schemas) with document validation support. In addition, it will also address document views and formatting, key events and event groups. First public working drafts are available on the W3C website.
3. An Application of DOM
The following example will illustrate the use of Dom parser in a JavaScript application to convert prices from U.S. dollars to Euros. The price list is the XML document used in listing 1 (prices.xml). The following is the HTML page for the application:
Then here is the listing of the JavaScript for the application:
function convert(form,xmldocument) {var fname = form.fname.value, output = form.output, rate = form.rate.value; output.value = ""; var document = parse(fname,xmldocument), topLevel = document.documentElement; searchPrice(topLevel,output,rate);} function parse(uri,xmldocument) {xmldocument.async = false; xmldocument.load(uri); if(xmldocument.parseError.errorCode != 0) alert(xmldocument.parseError.reason); return xmldocument;} function searchPrice(node,output,rate) {if(node.nodeType == 1) {if(node.nodeName == "price") output.value += (getText(node) * rate) + "\r"; var children, i; children = node.childNodes; for(i = 0;i < children.length;i++) searchPrice(children.item(i),output,rate);}} function getText(node) {return node.firstChild.data;}
Note that this application is specific to Internet Explorer 5.0. III. The SAX Parser:
1. What is SAX?
SAX (the Simple API for XML) is an event-based parser for xml documents. The parser tells the application what is in the document by notifying the application of a stream of parsing events. Application then processes those events to act on data. SAX is very useful when the document is large.
SAX 1.0 was released on May 11, 1998. SAX is a common, event-based API for parsing XML documents, developed as a collaborative project of the members of the XML-DEV discussion under the leadership of David Megginson. Relative to the preliminary draft version of SAX released in January 1998, SAX Version 1.0 represents a major reimplementation, adding some important features such as the ability to read documents from byte or character streams.
2. Why SAX?
Many might ask: why do we need another parser? The answer is in the following:
For applications that are not so XML-centric, an object-based interface is less appealing. Indeed, those applications have their own data structure and their own objects, which are not based on XML. For these applications, it is more sensible not to build the DOM tree, but to directly load the document in their data structure. Otherwise, the application has to maintain two copies of the data in memory (one in the DOM tree and one in the application’s own structure), which is inefficient. This might not be a problem for desktop applications, but can bring a server down to its knees.
Another reason why people prefer event-based interfaces is efficiency. Event-based interfaces are lower level than object-based interfaces. On the positive side, they give you more control over parsing and enable you to optimize your application. On the downside, it means more work for you.
As already mentioned, an event-based interface consumes fewer resources than an object-based one, simply because it does not need to build the document tree.
Finally, with an event-based interface, the application can start processing the document as the parser is reading it. With an object-based interface, the application must wait until the document has been completely read.
Therefore, event-based interfaces are particularly popular with applications that process large files (which would take a lot of time to read and create a document tree) and for servers (which process many documents simultaneously).
However, the major limitation of event-based interfaces is that it is not possible to navigate through the document as you can with a DOM. Indeed, after firing an event, the parser forgets about it. As you will see, the application must explicitly buffer those events it is interested in. It might also have more work in managing the state.
3. SAX API
As we said SAX is an event-based parser. As the name implies, an event-based parser sends events as it reads through an XML documents. Parser events are similar to user- interface events such as ONCLICK (in a browser) or AWT events (in Java). Events alert the application that something happened and the application might want to react. Applications register event handlers, which are functions that process the events. In a browser, events are typically generated in response to user actions: The user clicks on a button, the button fires an ONCLICK event. With an XML parser, events are not related to user actions, but to elements in the XML document being read. There are events for:
Element opening tags Element closing tags Content of elements Entities Parsing errors
4. An Application of SAX:
To understand how an event-based API can work, consider the following sample document:
An application handles these events just as it would handle events from a graphical user interface: there is no need to cache the entire document in memory or secondary storage. An event-based interface is the most natural interface for a parser. Indeed, the parser simply has to report what it sees. Note that the parser passes enough information to build the document tree of the XML documents but, unlike an object-based parser, it does not explicitly build the tree.
IV. Conclusion:
DOM is mostly used because it’s more available than SAX and supported by many applications and organizations. Still, there are cases when SAX might be more efficient.