 |  |
| |
Producers and Consumers
Beginning SAX
Basic ContentHandler Events
Producer-Side Validation
Exception Handling
Namespaces and SAX2
SAX gets its power from the unifying notion that sequences of event callbacks are powerful and lightweight ways to represent the information in XML documents. Building on that notion, you can create many powerful tools. Most of the essential SAX calls use interfaces, so the interesting behavior comes from how you combine implementations of those interfaces to assemble tools and what those implementations do.
This chapter shows the basic structure of SAX and of several classic SAX applications using an XML parser, the "simple" core of SAX. It starts by showing the essential components and the framework through which they relate. Then it shows how to customize the most important features and concepts in that framework and how to work with the core XML data model of elements, attributes, and text. You'll also see how to handle errors and learn how SAX exposes XML namespaces.
This chapter focuses on the parts of SAX that essentially every application needs to know. It doesn't provide full information about every interface. Later chapters elaborate on these structures and concepts, showing additional parts of these APIs, ways to combine SAX components, and how to work with additional parts of the XML data model. Depending on what your application needs to do, you may not need to know much more of SAX than is explained in this chapter.
The first thing to learn is that there are really two kinds of roles in this API -- or three, if you include your role as director, configuring sets of components to serve those roles and provide your application's functionality. Complete SAX applications integrate all these roles.
The first role is an event producer, which is typically an XML parser packaged as an instance of some library class. The producer is in charge of pushing parsing events to objects that serve the second role: an event consumer. Most SAX applications will only have one event producer, though we'll look at some cases where you need more than one. This chapter touches on several of the ways to configure (or customize) event producers.
Consumers normally do most of the "real" work for any given SAX-based application: they make sense of the parsing events and often create some specialized data structures. Without a consumer to handle events, nothing happens! SAX2 defines several kinds of handlers to consume different parts of the XML content. Later chapters look at each kind of handler in detail, but in this chapter we look only at the most important methods and handlers.
When we show SAX components connecting, we'll use diagrams like Figure 2-1, with the dashed lines indicating individual event handlers. There are four of them because there are four handlers used to deliver content to consumers. The producer uses a big arrow, which should remind you in which direction it pushes events.
When you're using SAX, any or all of these components can be provided by your application or can be library components. Often you'll use an XML parser from a library to produce events, but in other cases applications produce such events directly.
|  | |
| 1.8. What XML Are We Talking About? |  | 2.2. Beginning SAX |
Copyright © 2002 O'Reilly & Associates. All rights reserved.