SAX (Simple API for XML) like DOM (Document Object Model) gives access to the information stored in XML documents using any programming language (and a parser for that language). However, both of them take very different approaches to giving you access to your information: DOM creates a tree of nodes (based on the structure and information in your XML document) and you can access your information by interacting with this tree of nodes.

SAX parsers report content to applications as a series of events corresponding to document content. SAX filters take that information, do something to it, and pass it on to another process.

OASIS is now the official host of the XML-DEV mailing list. The move has prompted some discussion concerning the role OASIS might serve within the XML community. The focus is on the future development and potential standardization of SAX. SAX (Simple API for XML) was developed collaboratively on the XML-DEV list and coordinated by David Megginson.

One of the standard questions about generating non-XML output from an XML document is how to produce CSV, and a natural generalization is how to produce multi-level delimited output with a comma for one level, a semi-colon for the next, etc. This task can be accomplished with XSLT, but it can also be accomplished (perhaps more simply) with SAX and Java.

Earlier on we learned that the DOM gives us the ability to access the tree structure that underlies the parsed document. What we ideally need for our RSSApplet is a function that lets us address a specific element in the tree and have the content returned. For tree navigation, the W3C defined the XPath specification, allowing us to specify nodes in a manner similar to the way we would specify files in a hierarchical directory structure.

People have always liked to complain that Python is slow. People have always liked to complain that XML processing is slow. I've always thought both complaints are typically misguided. Neither Python nor XML emerged out of the need for ultrasonic speed at runtime. Python emerged as an expressive language for programming applications, and XML as an expressive system for building data representation into applications.

Sax ActiveX Comm Objects is an easy-to-use ActiveX control and COM object that lets you add powerful, multi-threaded communications capabilities to your 32-bit Windows applications. Sax ActiveX Comm Objects is upward compatible with the MSComm control that comes with Microsoft Visual Basic and with Crescent's PDQComm.

Simple API for XML (SAX) is an event-driven interface in which an application supplies the parser with ``callback'' event handlers that are invoked when certain parsing events occur.

In Chapter 5 we looked at how to write applications using the Document Object Model. In this chapter we'll look at an alternative way of processing an XML document: the SAX interface. We'll start by discussing why you might choose to use the SAX interface rather than the DOM. Then we'll explore the interface by writing some simple applications. We'll also discuss some design patterns that are useful when creating more complex SAX applications, and finally we'll look at where SAX is going next.

The classes, methods, and features described below are not commonly used in most applications and can be ignored by most users. If however you find that you are not getting the granularity you expect from Basic SAX, this would be the place to look for more. Advanced SAX isn't advanced in the sense that it is harder, or requires better programming skills. It is simply more complete, and has been separated to keep Basic SAX simple in terms of the number of events one would have to deal with.

SAXCount and DOMCount invoke the parser on an XML document, and print out information about the document. By default, SAXCount creates a non-validating SAX parser and DOMCount creates a validating DOM parser. They both count the number of elements, attributes, text characters, and ignorable whitespace characters in the document and display the amount of time it takes to complete the task.

In real life, you are going to have little need to echo an XML file with a SAX parser. Usually, you'll want to process the data in some way in order to do something useful with it. (If you want to echo it, it's easier to build a DOM tree and use that for output.) But echoing an XML structure is a great way to see the SAX parser in action, and it can be useful for debugging.

Now you should have a pretty good idea about what a SAX parser is, and how you might implement one using a state machine design. Now it is time to learn how to implement the parser using libxml's C translation of the SAX interface.

Jon Bosak has urged that future development of SAX should be conducted in a "properly constituted OASIS technical committee".

The SAX API provides an event-oriented API for interacting with an XML parser, but there is no reason that a source of SAX events should necessarily be an XML parser processing XML markup. That source could just as easily produce events based on the results of a database query, a flat file, an EDI message, or something else altogether.

SAX for Pascal - Simple API for XML Interfaces

In a previous column, we covered the basics of the Simple API for XML (SAX) and the modules that implement that interface in Perl. Over the course of the next two months we will move beyond these basic topics to look at two slightly more advanced ones: creating drivers that generate SAX events from non-XML sources and writing custom SAX filters. If you are not familiar with the way SAX works, please read High-Performance XML Parsing With SAX before proceeding.

You WebReference readers are never content. Once you have the desired functionality in place in an applet you wonder whether it could be done in half the space. And you are absolutely right: It can be done! In this column, we'll trim our RSS viewer down to size, and we'll also discuss different XML processing styles along the way.

A SAX parser can report contiguous text using multiple characters events. This is often unexpected and can cause obscure bugs or require complicated adjustments to SAX handlers. By inserting text_normalize_filter into the SAX handler chain all downstream parsers are ensured that all text nodes in the document Infoset are reported as a single SAX characters event.

SAX (Simple API for XML) is a common parser interface for XML parsers. It allows application writers to write applications that use XML parsers, but are independent of which parser is actually used.