SAX: Next Round

[Lars Marius Garshol]

* Bill la Forge
|
| public abstract class Filter
|  implements Parser, DocumentHandler, DTDHandler, EntityResolver, 
|             ErrorHandler {

What I had in mind was something more on the lines of:

  public interface EventSource {
     // basically equivalent to Parser
  }

  public interface ParserFilter extends EventSource {
     public void setEventSource(EventSource es)
  }

  public interface EventFilter {
     public void setEventReceiver(EventReceiver er)
  }

and then in the application

  public class NamespaceFilter implements ParserFilter, EventFilter {
    ...
  }


This would allow Filters to present different views from both
directions, and should be able to accomodate both John's approach as
well as yours.

The trick is making it backwards-compatible and natural. Whether we
can do that is an open question.

Do we aim for binary backwards compatibility (integration with class
files compiled to SAX 1.0) or do we just aim for a SAX 2.0 that SAX
1.0 applications can be compiled unchanged against? The latter case
gives us a lot more flexibility, methinks.

--Lars M.


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