SAX 2.0 extension proposals.

Miles Sabin msabin at
Wed Feb 2 13:55:04 GMT 2000

Toby Speight wrote,
> [snip: XMLImplementation and filters]
> It would be nice if Miles gave some thought to this issue.  
> Perhaps it's an insoluble problem; perhaps filters need some 
> additional feature types (or additional queries on those 
> features) to indicate how the the upstream parser's behaviour 
> is modified.

Actually, I don't think there's a problem here. The
org.xml.sax.helpers.XMLFilter itself isn't intended to be
used directly ... it's meant to be extended by SAX applications
(David: I think it should be marked as abstract). That being
so, there's no reason for it to have a corresponding concrete

Now, if you extend it,

  public class MyFilter
    extends XMLFilter
    // override methods as required

you could do something like this,

  public class MyFilterImpl
    implements XMLReaderImplementation
    private XMLReaderImplementation itsBaseImpl;

    public MyFilterImplementation()
      // Locate a base implementation to wrap
      // MyFilter's around.

      itsBaseImpl = 
          getImplementation(... features wanted ...);

    public boolean supportsBoolean(String name, boolean state)
      // Just pass through here, but we could adapt

      return itsBaseImpl.supportsFeature(name, state);

    public XMLReader createReader()
      return new MyFilter(itsBaseImpl.createReader());

and add a provider file pointing to MyFilterImpl.

I'm not sure that this solves _all_ the problems, but it looks
like it covers quite a few cases.



Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions and unsubscriptions
are  now ***CLOSED*** in preparation for list transfer to OASIS.

More information about the Xml-dev mailing list