OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Reusing, Refactoring, Reinventing??? (was Re:[xml-dev] SAX

[ 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, 

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 

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
   Effective XML (Addison-Wesley, 2003)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS