Tom Palmer wrote:
>
> > When we talk about serializing the DOM, what are we talking about now? You
> > will always have to qualify this with "er Java Serialization" or "no.. the
> > xerces serialization package/mechanism."
> >
> As I mentioned before when we all sent emails with our
> different opinions, you could call it:
>
> DOM Serialization
>
> Not too bad. I'm not unwilling to have it go by a different
> name (though I think we all settled on serialization already),
> but I do not think this is so confusing.
In fact this is what really is.
Look, the serialization design pattern (which has already a wrong name
since it should be "marshaller") says that you "write an object
representation to a stream, so that all the non-transient information is
saved".
If you have DOM that serializes itself using the XML syntax, this is
serialization. In fact, if you consider an example like this (I know
it's incredible, but I've seen this implemented with my eyes in Sweden
last week!)
- your have a DOM view of your database
- you want to edit the file with your favorite text editor via FTP
- you want the changes to be back on the database
What's done here is "serialization" (marshalling) of the DOM to the
editor and "deserialization" (parsing) when the text is saved and
FTP-sent to the remote DOM.
Would you call this "printing"? "output-handling"?
So, if you want to do "DOM Serialization" you still have to specify
"how". This is also true for Javadocs in Java 1.2. You can implement a
DOM that serializes itself using the internal Java serialization
paradigm but using a canonical XML syntax. What's wrong with that?
Confusing? Maybe, but this is just because some think about the API not
the design ideas behind them.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
