SAX questions

David Megginson david at
Wed Jul 22 22:44:47 BST 1998

Patrice Bonhomme writes:

 > 1/ For instance, the construction of the tree is supporting by the
 > parser (with some insertLast(...)).  Do i need to transfer the tree
 > construction within the "default XML handler" ?

SAX can work as an iterator over a tree, but it is suboptimal: a good
iterator would return each tree node.  For my MSXML SAX driver, I
explicitly disabled tree construction, since the greatest advantage of
an event-based (or streaming) API is the light resource usage.

 > 2/ What about CDATA sections, XML declaration, and validation
 > processus ?

CDATA sections and the XML declaration may both be included in a
level-two SAX, aimed at authoring tools, but they are not relevant for
the down-level processing tasks (such as formatting or database
import) which were SAX's initial target.

The user chooses validation or non-validation implicitly through the
selection of a SAX driver; SAX itself has no facility for turning
validation on or off, though it does allow an application to
distinguish validation errors from well-formedness errors (and to
ignore validation errors if desired).

 > 3/ If i understand the event-based philosophy, an XML parser do not
 > need to know something about DOM objects (no "new Element()", "new
 > Comment()" called within the code of the parser !) ?

The level-one SAX does not report comments.  If you are using
FREE-DOM, you can let FREE-DOM take care of node creation; if you are
building your own DOM using SAX, then you should create nodes inside
the handlers.

 > 4/ Is there a kind of "blue print" for developping an event-based
 > XML parser ?

Not specifically, but if you have access to a copy of DESIGN PATTERNS
(Gamma, Helm, Johnson, and Vlissides) take a look at the Visitor
pattern on page 331.

More usefully, many of the existing XML parsers come with source code,
so dive in!

All the best,


David Megginson                 david at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list