[jdom-interest] Thoughts on...

[philip.nelson at omniresources.com]

> That sounds fair enough...if it's already been discussed before...
> 
> But beware...you haven't heard the last from me on this 
> issue...once it gets
> rolled into Java proper I will be raising a feature request!!!
> 

Good deal ;^)

> I still don't believe, given JDOM's seemingly real goal, that 
> having support
> for Strings only is gonna be good enough for the future...I 
> will acquiesce
> for now...

I re-read what you said JDOM's real goal is

>>>
Consider, a Document is designed to be a Java representation of any
document, not just XML and not just for visual purposes, for JDOM to be
really useful it must also allow Documents to live ONLY in memory, or to be
passed via RMI.  In which case having content living as a String would be
cumbersome and painful.  Also, having the data conserved in the format that
it was generated in is also important, i.e. the recevier object would not
have to do a best guess conversion...
>>>

We had a very long and interesting discussion about that as well.  Brett
said that in his view, using JDOM across RMI was a very bad idea.  He went
so far as to see that people are infatuated with XML and are trying to use
xml in places that is simply shouldn't be used. His point was (among others)
that your business class may need the services of an xml api, but that the
heart of your business classes should *not* be or even possibly contain xml
documents. I was talking about having JDOM elements as part of my own
classes in a has-a relationship in cases where a primary function of the
class was to exchange information via xml. My point was that there are valid
reasons you may want to do this. Many people here seem to be interested in
building their own classes by extending JDOM classes to implement a is-a
relationship.  In these two cases, implementing serializable is an issue.
Aside from any issues dealing with primitive type conversions, you have a
great deal of overhead just because it's XML.  This is greatly magnified if
you extend your classes to the RMI or EJB environments, where serializable
is used constantly.  In addressing that, Brett discussed the merits of
custom Value pattern classes to pass data across RMI while on the other
side, Elliotte Rusty Harold advocated complete serialization to a string to
pass via RMI or other protocol, the SOAP style use of XML.  

I think that the intent of the authors was not to create "a Java
representation of any document, not just XML".  It was to create and XML
object library for java.  Hopefully my heavily paraphased and personal
interpretation of these things is accurate. Now, having said all that, we
created an api and people will use it in many ways not expected or intended.
The better the api, the more likely this is to happen.  Over time, use cases
may change.  That's why the more recent effort to make it easier to extend
jdom makes sense.  But for release 1.0, there is enough to do :-)