A Proposal for Refactoring SAX

[Miles Sabin]

[Note: resend. xml-dev at majordomo.ic.ac.uk seems to be
 a bit touchy at the mo']

Andy Clark wrote,
> Miles Sabin wrote,
> > I think we need a bit more detail, because, on the
> > face of it your proposal *completely* breaks both
> > forwards and backwards compatibility with SAX1.
>
> That's pretty much the question that we have to 
> answer: do we completely break the compatibility with 
> the old APIs to design the new SAX right; or do we 
> limit the growth of SAX because of the legacy issue?

Well, in its favour, your proposal would allow for
adapter classes (SAX1->SAX2 and SAX2->SAX1) which
lessens the impact somewhat.

In line with the new naming scheme we would probably
want to introduce some new system properties,

  org.xml.parser.stream  Name of stream parser class
  org.xml.parser.dom     Name of dom parser class

Consequently we could provide a SAX1 to SAX2 parser
adapter as follows. A SAX2 client app that wants
to interoperate with a SAX1 parser could define
org.xml.parser.stream as, eg.

  org.xml.parser.compat.SAX1Adapter

and org.xml.sax.parser as,

  com.foo.sax.LegacyParser

SAX1Adapter could be defined as thus,

  public class SAX1Adapter
    implements org.xml.parser.stream.Parser
  {
    private org.xml.sax.Parser itsAdaptee;

    public SAX1Adapter()
    {
      itsAdaptee = org.xml.sax.helpers.
        ParserFactory.makeParser();
    }

    // SAX2 parser methods forwarded to contained
    // SAX1 parser. Note there'd need to be
    // some juggling of argument types (because
    // they'll have shifted packages too) but
    // nothing particularly difficult.
  }

The SAX1 ParserFactory would resolve the SAX1 Parser
implementation via the old SAX1 system property.

Going in the opposite direction a SAX1 client app that
wants to use a SAX2 parser could set org.xml.sax.parser
to,

  org.xml.parser.compat.SAX2Adapter

and org.xml.parser.stream.parser as,

  com.foo.sax.NewParser

We then define SAX2Adapter similarly,

  public class SAX2Adapter
    implements org.xml.sax.Parser
  {
    private org.xml.parser.stream.Parser itsAdaptee;

    public SAX2Adapter()
    {
      itsAdaptee = org.xml.parser.stream.helpers.
        ParserFactory.makeParser();
    }

    // SAX1 parser methods forwarded to contained
    // SAX2 parser. Note there'd need to be
    // some juggling of argument types (because
    // they'll have shifted packages too) but
    // nothing particularly difficult.
  }

Incidently, I'm quite keen on the DOM parser stuff.
That'd ease some of the problems that the DOMs
current lack of a portable way of creating Documents
causes.

> I like your refactorization better! :) It's still
> clean and separated for everyone to have a standard
> way of doing things.

That ain't refactoring (not in my book anyway) I just
changed a few of the names ;-)

Cheers,


Miles

-- 
Miles Sabin                          Cromwell Media
Internet Systems Architect           5/6 Glenthorne Mews
+44 (0)181 410 2230                  London, W6 0LJ
msabin at cromwellmedia.co.uk           England

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/ and on CD-ROM/ISBN 981-02-3594-1
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)