I am evaluating migration of a project from JAXP to JDOM. Although JDOM looks more clean to work with and to some extent workable with org.w3c.dom Interfaces, It doesnt really follow the W3C Interfaces. Does this not mean locking with a particular API. I suppose once it becomes a part of JDK, then it is not so important to follow W3C standards because Java is still controlled by sun. But if sun starts following a different Interface specification the the W3C one, where would it leave people who use Java Parsers confirming to W3C standards.. Any views..
I think you are getting confused here. JAXP and JDOM has nothing in common. Atleast they are not mutually exclusive technologies. DOM spec is controlled by W3C. Any DOM parser must comply with the DOM spec published by W3C. JDOM is no exception. JDOM only simplifies manipulating the components of the DOM tree. In the "raw" version, all standard DOM parsers deal directly at the level of the interfaces specified by W3C. Although this works, it may not be the most efficient way of dealing with a group of "similar" objects, given that Java provides such nice collection classes. JDOM attempts to provide a layer around the standard W3C parser so that the objects returned by various DOM methods can be manipulated as standard Java collections( java.util.* ). The usability of JDOM has made it very popular among Java developers. Sun finally considered it for a JCP( Java Community Process ). It will shortly be a standard part of JDK. Again, it is not going to replace JAXP! It is an addition to standard XML support provided by Java. Hope that helps! ------------------ Ajith Kallambella M. Sun Certified Programmer for the Java�2 Platform. IBM Certified Developer - XML and Related Technologies, V1.
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
posted 17 years ago
thanks for reply, however the confusion still persists.. if you look at http://www.w3.org/DOM/2000/12/dom2-javadoc/index-all.html this looks like a specification that all java parsers must follow. However the Element class defined by jdom (http://www.w3.org/DOM/2000/12/dom2-javadoc/org/w3c/dom/Element.html) java.lang.Object | +--org.jdom.Element doesnot implement the Element interface defined by w3c.Nor could I find any other jdom class which does implement this Interface. So for example if you are using JAXP and JDOM in the same project, and come across an object which is referred to by an Element, it could get confusing. And so on.. I understand that it is possible to transform the jdom Document into org.w3c.dom.Document org.w3c.dom.Document domDocument = outputter.output(myDocument); But this looks more like a facility to allow compatibility with XSLT engines which do not support JDOM Document yet. So in the end, I dont know if JDOM can be treated as either an implementation of W3C.DOM or as another layer on top of JAXP. Do correct me if I am wrong.
While JDOM interoperates well with existing standards such as the Simple API for XML (SAX) and the Document Object Model (DOM), it is not an abstraction layer or enhancement to those APIs. Rather, it seeks to provide a robust, light-weight means of reading and writing XML data without the complex and memory-consumptive options that current API offerings provide.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
More likely, you will use a JAXP1.1 compliant parser behind JDOM, save your tons of time of development and headache.
posted 17 years ago
Michael Champion (Member of the W3C's DOM Working Group and Senior R&D Advisor, Software AG) as said on the xml-dev mailing list
"The world can alway vote with its feet and override the votes of any standards committee. If the XML family of technologies do indeed prove too obfuscated for the needs of industry, we can expect "YML" or "ZML" or whatever to come along and rectify the mistakes that we refuse to face up to. We've seen Java get a lot of acceptance by addressing the "mistakes" in C++, and we see C# trying to address the "mistakes" in Java. We already see JDOM addressing the "mistakes" of the DOM, RELAX addressing the "mistakes" of XSD, etc. The marketplace of money and ideas, not the W3C or ISO, will ultimately decide which specs prevail."