SAX 1.0 has been very widely implemented and has been in widespread use almost since the day the first draft appeared on 12 January 1998 - a month earlier than the date of the final XML 1.0 recommendation. It has met user needs well, in spite of a few criticisms, some of which are hinted at in this chapter. So it is perhaps unsurprising that the development of a successor, SAX 2.0, has been comparatively leisurely.

An alternative way of structuring a SAX application, which again has the objective of separating functions and keeping the structure modular and simple, is a rule-based approach. In general rule-based programs use an "Event-Condition-Action" model: they contain a collection of rules of the form "if this event occurs under these conditions, perform this action". Rule based programming can thus be seen as a natural extension of event-based programming.

Our example SAX applications have only been interested in processing one or two different element types, and the processing has been very simple. In real applications where there is a need to process many different element types, this style of program can quickly become very unstructured. This happens for two reasons: firstly, the interactions of different events processing the same global context data can become difficult to disentangle, and secondly, each of the event-handling methods is doing a number of quite unrelated tasks.

The features we've covered so far are probably enough for 90% of SAX applications. But it's useful to know something of the rest of the features, for those occasions when they are needed. This section of the chapter gives a survey of these features and their intended purpose.

The history of SAX is unusually well documented, because all the discussion took place on the public XML-DEV mailing list, whose archives are available at http://www.lists.ic.ac.uk/hypermail/xml-dev/. David Megginson has also summarized its history at http://www.megginson.com/SAX/history.html.

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.

With XML only consisting of data content, there is a clear need for ways to display this content. This is commonly referred to as 'styling the content'. At the time of writing, there are two W3C standard stylesheet languages: CSS (Cascading Stylesheets) and XSLT. Both can be used to assign certain looks to specific element types in an XML document.

XSLT processor vendors are free to add their own private extensions to the language. The XSLT specification even specifies how they should indicate if an extension element or extension function is supported by their implementation.

Once you have read this section, you will have found out that its title is a bit deceptive. You, as a programmer, have certain expectations about a new programming language when you start learning it. One of them is that you expect it to be possible to store values in variables, change them and retrieve them later. Although XSLT has an element called variable, you actually cannot do much with it. This may sound unbelievable, but it is a result of the way XSLT works that you cannot have variables. This is a thing that beginning XSLT programmers have many difficulties grasping.

First of all a warning: be careful - the eval and script elements are not specified in the XSLT recommendation. They are Microsoft extensions, available only in their MSXML implementation. So, if you want to be able to switch XSLT implementations later on, do not use these features.

When we want to exchange information with other applications, it would be nice if everyone would use the same document types (that is use the same validation rules). However, it is inevitable that, for comparable types of data, several document types will emerge. Some repositories will emerge, where schemas and DTDs can be stored and shared. Often these are industry-wide initiatives. However, several schemas for the same data will exist.

Now we have an easy and platform-independent method of describing XML data, validating its type as we wish and modifying and reading it programmatically. So we basically have a transportable miniature database. No surprise then that when you start to work with it, you'll feel the need for a query mechanism. Using the DOM, you can get to each and every node in your document, but it can get tiresome, maneuvering through the hierarchies of children to find that single node you are interested in.

An XML processor is more commonly called a parser, since it simply parses XML and provides the application with any information it needs. There are quite a number of XML parsers available, many of which are free.

Although it isn't all that common, sometimes you need to embed application-specific instructions into your information, to affect how it will be processed. XML provides a mechanism to allow this, called processing instructions or, more commonly, PIs.

This section describes empty elements and XML declaration in XML.

Comments provide a way to insert into an XML document text that isn't really part of the document, but rather is intended for people who are reading the XML source itself.

In addition to tags and elements, XML documents can also include attributes.

This chapter will cover all you need to know to create "well-formed" XML. Well-formed XML is XML that meets certain grammatical rules outlined in the XML 1.0 specification.