A Proposal for Refactoring SAX

[Miles Sabin]

Andy Clark wrote,
<snip/>

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.

I *presume* that in addition to your proposal you have
in mind that a SAX2 parser could also be a SAX1 parser
(at least until SAX1 is retired) which would allow SAX1
clients to interoperate with SAX2 parsers. And I
*presume* that you envisage an adapter that would allow
a SAX1 parser to be presented as a SAX2 parser, allowing
SAX2 clients to interoperate with older parsers.

If those two assumptions are right, then your proposal
looks fairly plausible, with the proviso that updating
clients and parsers for SAX2 will involve (admittedly 
trivial) recoding which could slow migration. I'm not 
convinced that this is a better bet than simply adding 
new methods to the old interfaces ... but I have to 
admit that that approach has its own problems as my own 
contributions to the various related threads testify.

I think that the biggest problems are likely to be 
namespace and naming issues. In your breakdown of the 
post-refactoring situation you've put the core classes 
and interfaces under org.xml. Then in your discussion 
you write,

> A simple solution for not breaking SAX 1.0 
> compatibility would be to move the new org.xml.sax 
> interfaces and classes into a package named 
> org.xml.sax2.

Again, I'm assuming that org.xml is being taken as
being preferable to org.xml.sax[2].

Unfortunately, neither of these options are particularly
nice. org.xml is problematic, because it limits the 
scope for other, future, functionally unrelated APIs, to 
be released in the org.xml namespace. org.xml.sax2 is 
just plain nasty, and quite likely to be error prone 
(I'm sure *I*'d forget the '2' quite frequently ;-)

Given that you're suggesting, what is, in effect, a
completely new API, why don't we go for a namespace
that looks something like this,

  org
    xml
      parser
        EntityResolver
        ErrorHandler
        InputSource
        Locator
        Parser
        ParserException (was XMLException) 
        ParseException  (was XMLParseException)

        helpers
          LocatorImpl
          ParserFactory

        stream
          AttributeList
          DocumentHandler
          DTDHandler
          HandlerBase
          StreamParser (was SAXParser)
        
          helpers
            AttributeListImpl
            StreamParserFactory (was SAXParserFactory)

        dom
          DOMParser

          helpers
            DOMParserFactory

      sax
        // SAX1 stuff here

        helpers
          // SAX1 stuff here

There's no more effort involved in switching over to
this namespace structure that the one you've proposed,
and it has the advantage that the names are a little
more meaningful ... which'd be useful for novices.

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)