[
Lists Home |
Date Index |
Thread Index
]
- From: Miles Sabin <msabin@cromwellmedia.co.uk>
- To: "'xml-dev@ic.ac.uk'" <xml-dev@ic.ac.uk>
- Date: Tue, 25 May 1999 19:25:35 +0100
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@cromwellmedia.co.uk England
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|