Next Round

Bill la Forge b.laforge at
Thu Jan 21 02:53:53 GMT 1999

Lexical Event Handler

I think it would be particularly handy if LexicalProcessor extended DocumentHandler.

Given a document handler object, the parser could simply check to see if it was also 
an instance of LexicalProcessor and, if it was, pass it the additional events.

My reasoning here is that many of the events associated with LexicalProcessor would
likely need to pass through the same filters as the DocumentHandler events.

Mmm. Perhaps this could better be handled by splitting off the start/endDTD events and
placing them on an extension of DTDHandler.

Basically, I agree here with Don Park.

Namespace Support

Why not support Namespaces through a filter? Why put everything into a monilithic parser?
If we have good support for filters, then we can have a reasonable scope for parsers and
allow applications to configure their filters to meet their particular needs.

Filter Interface

We are looking at building trees of event filters in MDSAX, with event processing
dependent on document type, element type, and other application-specific considerations. An 
api which constrains filters to a simple sequence doesn't really get us where we want to go. 

Our hope is to support a variety of filter implementations, with the glue code hidden in
the filter factory which supports this interface:

public interface MDFilterFactory
  * Creates a chained document handler (a filter).
  public DocumentHandler
 createFilter(MDContext context, DocumentHandler nextHandler);

The third alternative, where filters extend DocumentHandler, would certainly be the easiest
to accomodate. 

And if LexicalProcessor extends DocumentHandler, then Filter should extend 
LexicalProcessor. This would really be ideal!


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