> 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
--
David Megginson david@megginson.com
http://www.megginson.com/