[
Lists Home |
Date Index |
Thread Index
]
At 10:39 AM -0500 11/9/03, Michael Champion wrote:
I thought the suggestion on the table was to standardize EXTENSIONS
to SAX to allow binary and/or typed data. It sounds like textbook
software engineering to me -- re-use what is common, add specialized
extensions for what is not common.
Optional extensions are harmful. Making the interface larger is
harmful. Simon, Scott, and I are already having conniptions trying to
figure out how to pack all the specs the W3C has shovelled out the
door into a nutshell. The bigger the specs get the worse the problems
become. And this isn't just a problem for the authors. The readers
and users get very confused over what they can, should, and should
not use. Smaller is better.
As to reuse, this is a textbook case of how not to reuse. The
mechanisms of reuse are composition and inheritance, and these are
placed in opposition to rewriting the code. Neither composition nor
inheritance is being proposed here. The suggestion is to rewrite the
code and interface to support the new features. I suppose you could
subclass ContentHandler with a TypedContentHandler that would have
the extra methods. In fact, there's nothing that prevents anyone from
doing this now. However, the argument is whether to put this into SAX
itself rather than somebody's personal local classes.
I'd further argue that doing this (extending ContentHandler with
TypedContentHandler) is not a good idea from OOP principles.
TypedContentHandler is not a ContentHandler. It merely acts like one.
A ContentHandler is an interface that receives data from an XML
parser or a filter that converts data into XML. A TypedContentHandler
is an interface that receives data from a non-XML source that
provides non-XML data. In fact, now that I think about it this way,
this is a classic example of misuse of inheritance: extending an
interface to pull in a few pieces of implementation.
Learning from SAX while forking / reinventing it seems to do what
everybody laments about the state of the software industry -- too
many wheels being reinvented, too little code being reused, resulting
in proprietary lock-in, unreliability of relatively untested code,
etc.
This would neither be a fork or a reinvention. It would be a new tool
to do a new job. You could argue that using a binary format at all
instead of real XML would lead to proprietary lock-in, unreliability
of relatively untested code, etc. You might well be right if you so
argued.
I haven't read/remembered every bit of this thread, but I thought the
"bloat" would be a couple of generic extension interfaces that would
be implemented (or not) depending on the needs of a specific parser.
That doesn't sound like "corruption" to me.
It's a bad idea on its own merits, optional or not. And it's hugely
confusing to developers.
I hvae to disagree with this sentiment. First, I doubt very much if
ordinary developers give a rat's patootie about the subtle
distinctions here, and they are so UTTERLY confused about the various
"XML" specs and APIs already that this is just a very small drop in
an immense bucket. Second, what's the difference between "learning
from XML" and "basking in XML's glory"? Why shouldn't anyone re-use
every bit of the XML corpus that works for their needs rather than
introduce possible sources of error?
Why shouldn't carpenters who've learned how to use a hammer, reuse
that hammer to pound screws? If it's not XML, don't expect to use XML
tools on it. What's next? Extensions to XSLT to handle JPEGs? An
XQuery function to read IEEE-754 floats from a binary file?
Developers are confused, and we certainly shouldn't confuse them more
if we can help it. To the extent that the patterns are the same,
learning can be shared. Developers who are familiar with the Observer
design pattern from the AWT or other APIs find ContentHandler easier
to learn than developers who have never encountered the Observer
design pattern before. But I certainly wouldn't suggest
ContentHandler should extend ActionListener just because they both
use the same design pattern. That would be madness, and a very poor
example of reuse.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
|
