[jdom-interest] Ampersand question

[Elliotte Rusty Harold]

At 3:28 AM -0700 7/13/00, Alex Chaffee wrote:
>Rusty -
>
>Your efforts are admirable!  I'm glad you're thinking and hacking on
>this.
>
>However, the architecture is misguided.  We do not need a separate
>class called XMLSerializer.  We already have one that does almost
>everything we want, called XMLOutputter.
>

I'm not trying to duplicate functionality in XMLSerializer. I'm 
trying to move functionality from XMLSerializer into XMLOutputter. 
The reason is this:

We've already seen that handling the encoding declaration properly is 
a really nasty can of worms, and indeed we probably can't do it in a 
guaranteed correct fashion if we allow people to pass in their own 
writers, which Jason says is necessary for servlets, and is thus an 
important thing to do. Therefore I want to take all the code in 
XMLOutputter that's dedicated to converting JDOM objects to strings 
and put it in XMLSerializer. This means that anybody who only wants 
strings (e.g. for debugging) won't have to worry about encoding 
issues. And we can make XMLSerializer guaranteed correct.

XMLOutputter will take care of moving the strings onto an output 
stream or writer as necessary. It will delegate all the detailed 
formatting of objects as strings to XMLSerializer. It will handle the 
encoding declaration, and all details that change when the encoding 
changes. This won't solve any of the problems of mismatched 
encodings, but it will at least not bring them up unless they need to 
be brought up. Furthermore, it will present a cleaner, simpler, more 
modular API that's easier for programmers to get a hold of.

Converting our XML objects to strings is really not the same 
operation as writing those strings onto output streams and I don't 
think they should be in the same class. In essence, I'm paralleling 
the DecimalFormat/OutputStream distinction that Java uses for writing 
numbers into text files and the console. In this case, though, I 
don't expect it to cause as much confusion because programmers won't 
be dragging along so many preconceptions from other languages.

You know, I was trying to think of a better name than XMLSerializer 
for the class since it really has nothing to do with object 
serialization. Maybe I should call it XMLFormat, and change the 
serialize() methods to format() methods.

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+