[jdom-interest] Thoughts on...
jonbaer at digitalanywhere.com
Thu Mar 15 19:47:56 PST 2001
Amen to that =)
I am currently using JDOM in an Artificial Intelligence project involving
object-oriented databases. I think the power of where it comes from is the
underlying Collections API but to be able to do something with it like representing
XML is a bright idea and it makes alot of things easier. Out of 4 of my last
projects, all of them were better off including JDOM as its core for many things and
the SQLBuilder I wrote a while back was evidence to me that JDOM had real power in
ease and flexibility for any project.
I wouldnt be suprised if alot of people were using it in some way shape or form for
XML Data binding. Anyone?
Gary Bentley wrote:
> I agree!!!
> However, I think the authors of JDOM should be aware that JDOM has much more
> potential than just XML...it really does provide a way of representing a
> document in Java...as such I can see many more applications for it than just
> XML (which personally for me is a means to an end). The JDOM, for me at
> least, is a very good way of representing relational data and a very good
> and easy way of converting that data into an object heirachy. I can see it
> being very useful for a B2B application where each side may have custom
> objects but need an implementation independent method of transfering data
> between each other. RMI would in that case be an example of how the B2B
> could talk...
> Also, other examples are say that in a company you have a large system that
> needs data transfer between different parts of the system but does not want
> to rely on the object in any specific part, JDOM would be perfect for
> transfering the data without different parts of the system having to have
> specific knowledge of each other, they could define an interface that others
> could easily plug into without having to have the objects there to do so...
> The reason why I bring this kind of thing up is because if I've thought of
> it, then when JDOM gets accepted by the community at large then bigger
> brains than mine will be clammering for that capability...
> (Also, I did read in the slides that JDOM was able to represent any
> For JDOM to be only a library for XML is woefully underplaying it's
> potential...for such a wonderful tool I would hate to see it become only a
> library for XML...which there are plenty of anyway!!!
> Final thing...I have written libraries myself and then had to go back and do
> a rewrite when the use-cases change...please, please, please understand that
> JDOM will be used for more than just XML representations and don't restrict
> it to that only!!!!
> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of
> philip.nelson at omniresources.com
> Sent: Friday, March 16, 2001 2:49 PM
> To: jdom-interest at jdom.org
> Subject: RE: [jdom-interest] Thoughts on...
> > 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 :-)
> To control your jdom-interest membership:
> To control your jdom-interest membership:
More information about the jdom-interest