[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX: Next Round

• From: Lars Marius Garshol <larsga@i...>
• To: "XML Developers' List" <xml-dev@i...>
• Date: 22 Jan 1999 15:43:32 +0100

* 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@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • Re: SAX: Next Round
    • From: "Bill la Forge" <b.laforge@j...>

• Prev by Date: QName interpretation [Re: Next Round]
• Next by Date: Re: namespaces and document structure [Re: Next Round]
• Previous by thread: Re: SAX: Next Round
• Next by thread: Re: SAX: Next Round
• Index(es):
  • Date
  • Thread