SAX2 RFD: Inheritance vs. Modification vs. Amalgamation

[andyclar at us.ibm.com]

David Megginson wrote:
> 1. Create a new interface, org.xml.sax.Parser2, that extends
>    org.xml.sax.Parser.
> [...]
> 2. Add the methods to org.xml.sax.Parser, and require applications to
>   catch NoSuchMethodException when using the new methods, in case
>   they're concerned about what version they're dealing with.
> [...]
> 3. Create a separate interface org.xml.sax.ParserProps (or something
>    like that), and require SAX2 drivers to implement both interfaces.
> [...]

How about option 4...

4. Leave SAX 1.0 the way it is and place the new interfaces in new
   packages with the same names.

   PRO: Allows the members of xml-dev to design the new classes and
        interfaces without being hindered by subclassing/subtyping
        considerations.
   CON: Two separate (and similar in their base functionality) set
        of classes and interfaces.

I wrote to the list awhile ago about an idea to "re-factor" the
existing SAX classes and interfaces to make them more generically
useful. There was little response from the group. After getting a
response from David Brownell asking "Why do this?" and talking
to Lars M. at the XML Europe show, I got the impression that there
was no interest because noone understand what I was proposing. So
I'm back again to try to spark some interest in the idea.

The idea of re-factoring the API set comes from the work that I've
done on the IBM XML4J parser. Supporting the industry standards
meant that we included SAX 1.0 support as well as DOM 1.0. The SAX
community did it right and included interfaces for parsing, error
handling, entity resolution, etc. The DOM community has no such
concept, so parser implementors either a) have to make their own
proprietary way of loading documents and performing entity
resolution (among other things); or b) use the SAX classes. Most
parser implementations, including XML4J, use SAX 1.0 for the
features lacking in DOM (and other standards).

As a parser implementation, you don't want to publish a set of
streaming APIs for a parser instance that is *not* based on
streaming callbacks (startElement, etc). BUT... you *do* want to
have a generic error handling facility, entity resolution, and
ability to at least initiate a parse. For an example, look at
the Parser interface. Should a DOM parser be required to allow
people to register DocumentHandlers? Probably not, but you do
want methods like parse, setErrorHandler, and setEntityResolver.

In short, I would suggest that the useful classes and interfaces
from SAX 1.0 be moved to another package. Then, the interfaces
and classes considered to be part of SAX2 can live in a separate
package from the SAX 1.0 API. This would answer the question
of how to expand the existing interfaces because the old APIs
would not break.

I'm not a fan of really long posts so I'm going to post another
message with explicit details about which interfaces/classes
would move; where they would go to; and what benefits we would
get from the new separation.

--
Andy Clark * IBM, JTC - Silicon Valley * andyclar at us.ibm.com



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)