SAX: Next Round

Simon St.Laurent simonstl at
Thu Jan 21 12:48:38 GMT 1999

At 04:22 PM 1/20/99 -0500, david at wrote:
>I've been thinking about what new SAX interfaces we need the most
>(with much prodding from users).  

I'm very pleased to see this project getting going again.

>Here's what I think we need as a
>1. A standard filter interface (and perhaps an optional base class).
>2. A handler interface for lexical events like comments, CDATA
>   sections, and entity references.
>3. Some kind of namespace support.
>I'd like to lose EntityResolver and DTDHandler (who uses them?), but I
>don't know if we can.

I'd really prefer to go the other direction. In the course of writing and
working with filters, I've come to see them as a very powerful tool that is
hampered to a significant degree by the total lack of DTD information that
comes out of the parser.  Even if it's optional, I would _very_ much like
to see a set of events for DTD declarations - <!ELEMENT, <!ATTRIBUTE, etc.
If necessary, I'd be willing to do a lot of work in this area - after I
finish the current crushing load of books.

See for some of the
reasons I'd like access to this information.  Please keep in mind that it's
a very rough draft.

>1. Filter Interface

I think you may be doing too much to the filters themselves here; I'd
really prefer to see this coordination performed by an external framework,
like MDSAX (

>2. Lexical Event Handler
>What do we really need here?
>  public interface LexicalHandler
>  {
>    public void startDTD (String name, String pubid, String sysid)
>      throws SAXException;
>    public void endDTD (String name);
>    public void startExternalEntity (String name, String pubid, String sysid)
>      throws SAXException;
>    public void endExternalEntity (String name) throws SAXException;
>    public void startCDATA () throws SAXException;
>    public void endCDATA () throws SAXException;
>    public void comment (String data) throws SAXException;
>  }
>I haven't checked, but I think that this gives us everything we need
>for DOM level one.  

I'd like to have startInternalEntity as well; coupled with the DTD
declarations I mentioned above, it would let applications that found they
actually needed an external resource for processing get it, even in a
non-validating environment that didn't do that by default.

Also, going back to the DTD events, it would be useful to know which
attributes had assigned values and which were defaulted; I believe this is
also a DOM Level One issue.

>3. Namespace Support

This seems like something better done by a filter layer, provided we can
describe what the results of that processing should be.  It may take
extension of the API, or it may just take modification of element names, as
in John Cowan's NamespaceFilter (

Glad this is going again; SAX 1.0 did a great job for what it did, but I'd
like to see it present a more complete picture of documents.  

Simon St.Laurent
XML: A Primer / Building XML Applications (March)
Sharing Bandwidth / Cookies

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