XML was, as has been fretted over before, ugly, hard, and boring to code with. Not any more :). XOM rocks! I'm using it in all my projects now.
Keep it up!
--Patrick Collison
I did some XML Programming during the last month with Java's DOM. this was not funny !! I also played with Ruby's powerful REXML. this is a great API becaue it uses the power of Ruby and it was designed for Ruby and is not a generic interface like DOM. this is way REXML is so popular in the Ruby world.
and this is why I like XOM. for me it fits much better to Java than DOM. I hope that XOM will become for Java what REXML is for Ruby now.
--Markus Jais
Overall, I found XOM to be an amazingly well-organized, intuitive API that's easy to learn and to use. I like how it reinforces good practices and provides insight about XML -- such as the lack of whitespace when XML is produced without a serializer and the identical treatment of text whether it consists of character entities, CDATA sections, or regular characters.
I can't compare it to JDOM, but it's appreciably more pleasant to work with than the Simple API for XML Processing.
--Rogers Cadenhead
XOM has the best API ever.
In my app we churn business objects into XHTML then XSL:FO and finally PDF. XOM makes it super easy to build the XHTML tree. And if I play my cards right, I might be able to turn that XHTML into FO without serializing it to bytes first. Amazing.
XOM makes XML fun again! Get rid of SAX, DOM and hardcoded
"<html>". Get XOM, be happy.
--Jesse Wilson
XOM is the most correct and easiest to use XML tree and streaming API I've come across so far.
--Wolfgang Hoschek on the xom-interest mailing list, Wednesday, 5 Jan 2005 12:11:06
XOM is the most correct and easiest to use XML tree and streaming API I've come across so far.
--Wolfgang Hoschek on the xom-interest mailing list, Wednesday, 5 Jan 2005 12:11:06
i spent yesterday writing the code to render my application config as xml. using xom was like falling off a log. no muss, no fuss, the methods did what i expected, and any confusion was quickly ironed out by a visit to the (copious) examples, or the javadocs. i did run into what might be a bug, but it only showed up because i made a dumb cut-n-paste error (see my other email).
after i get the output tidied up, i'll move on to reading it back in. i'm confident that that will be almost as easy...
--Dirk Bergstrom
Event Based Push: SAX, XNI
Event Based Pull: XMLPULL, CyberNeko, StAX
Tree: DOM, JDOM, dom4j, Sparta, etc.
Data Binding: Castor, Zeus, JAXB, JaxMe, etc.
Read-only
Fast
Streamable
Memory efficient
Complete
Essentially correct
Client programs can get quite complex and confusing
Read-only
Fast
Streamable
Memory efficient
Client programs can be much simpler than SAX
Map XML documents to Java classes
Read/Write
Allow in-memory manipulation
Hide the XML details
Common assumptions:
Documents have schemas
Documents are valid.
Structures are fairly flat and definitely not recursive.
Narrative documents aren't worth considering.
Mixed content doesn't exist.
Choices don't exist.
Order doesn't matter.
Sees the world through object-colored glasses
Model an XML document using classes that represent nodes
Composition builds a tree
Read/Write
Allow in-memory manipulation
The simplest arbitrary XML API
Tend to be profligate with memory
Uses factories and interfaces, and yet not interoperable
Fails to enforce all XML constraints; allows creation of malformed documents
Namespaces properties and attributes
Live lists
Just plain ugly; does not adhere to Java conventions
No method overloading
Short type constants for node types
Methods in the Node superinterface that only work for one or two subinterfaces
Incomplete: no standard loading or serialization
A single exception class with short type codes
Does not guarantee Java features like equals(), hashCode(), and toString()
Had to be backwards compatible with unplanned object models in third generation web browsers.
Designed by a committee trying to reconcile differences between the object models implemented by Netscape, Microsoft, and other vendors.
A cross-language API defined in IDL
Needed to support weak scripting languages like JavaScript and AppleScript
Must work for both HTML and XML.
A node supertype is very useful
Interfaces are a bad idea
Successful APIs must be simple
Simplest of the previous APIs (but it could be simpler)
There's more than one way to do it:
3+ ways to read an attribute value
5+ ways to read a child element
Not always well-formed:
Processing instruction data
Text content
Internal DTD subset
Setter methods don't return void
Too weakly typed: Everything is an Object
Too strongly typed: nothing is a Node
Cloneable
Serializable
Many checked exceptions
Classes and constructors are good
Thread safety is not necessary
Live lists are trouble
Keep everything in one package
Don't release too early
Don't optimize until the API is right
You don't need to build your own parser, transformer, or search engine
You can fight the W3C
Forked from JDOM
More complex
Uses interfaces instead of classes
A complete streaming tree model for XML 1.0 instance documents
Free as in speech (LGPL)
Pure Java
Java 1.2 and later (internal dependence on Collections API)
Absolutely correct
Easy to use
Easy to learn
Fast enough
Small enough
No gotchas
All objects can be written as namespace well-formed, round-trippable XML text
Impossible to create malformed documents
Validity can be enforced by subclasses
Syntax sugar is not represented:
CDATA sections
Character and entity references
Attribute order
Defaulted vs. specified attributes
Principle of Least Surprise
As simple as it can be and no simpler!
Use Java idioms where they fit (and only where they fit)
There's exactly one way to do it
Start small and grow as necessary:
It's easier to put something in than take something out.
if I may make one point that highly influenced the end-game when we were finishing up XML 1.0 in 1998: if you leave something out, you can always put it in later. The reverse is not true.
--Tim Bray on the public-qt-comments mailing list
During the design I added methods that were necessary to produce certain sample programs.
Conversely I took things out no sample programs needed.
APIs are written by experts for non-experts
It is the class's responsibility to enforce its class invariants
Verify preconditions
Do not allow clients to do bad things.
The Iceberg Principle
Design for subclassing or prohibit it
Prefer classes to interfaces
Not thread safe
Classes do not implement Serializable; use XML.
Classes do not implement Cloneable; use copy constructors.
Lack of generics really hurts in the Collections API. Hence, don't use it.
Problems detectable in testing throw runtime exceptions
Assertions that can be turned off are pointless
This is a cathedral, not a bazaar
Unit testing
Static testing
Massive samples
"Premature optimization is the root of all evil" -- Donald Knuth, 1974
Pretty damn good
Fast enough
Certainly one of the most memory efficient, tree-based APIs; possibly the most memory efficient
1.1 is 2-4 times faster and somewhat smaller than 1.0. An iceberg API was essential in allowing optimizations to be made while mantaining backwards compatibility
There are tradeoffs between memory and speed.
Absolutely correct; no malformedness
Fewer "convenience" methods and classes
toXML()
JDOM Elements contain a list; a XOM Element is a list; thus
Typed navigation via loops instead of the Java Collections API, Lists, and Iterators
No support for skipped entities
XOM classes do not implement Serializable or Cloneable
Streaming
Canonical XML
XInclude
| Number of public methods (and constructors) in | DOM2 | JDOM | XOM 1.1 |
|---|---|---|---|
|
25 | 8 * | 13 |
Attribute |
5 | 29 | 20 |
Element |
16 | 73 | 37 |
ProcessingInstruction |
3 | 14 | 9 |
Comment |
0 | 5 | 9 |
Builder |
N/A | 32 ** | 16 |
Document |
17 | 41 | 13 |
| Total | 66 | 202 | 117 |
* Content
** SAXBuilder
DTD API
Catalog support
XML Encryption
XML Digital Signatures
Factories for DOMConverter
Overridable toString() method in Element for Steve Loughran
A few more optimizations
Joshua Bloch for Effective Java
Ken Arnold for Perfection and Simplicity
Bruce Eckel for Does Java need Checked Exceptions?
Bertrand Meyer for Object Oriented Software Construction
Jason Hunter and Brett McLaughlin for JDOM
Kent Beck and Erich Gamma for JUnit
The members of the xom-interest mailing list for numerous helpful suggestions and critiques
XOM Site: http://www.xom.nu/
XOM-interest mailing list: http://lists.ibiblio.org/mailman/listinfo/xom-interest
Getting Started with XOM by Michael Fitzgerald, http://www.xml.com/pub/a/2002/11/27/xom.html
XML Made Simpler by Rogers Cadenhead, Linux Magazine, March 2003, http://www.linux-mag.com/2003-03/java_xom_01.html
nu.xom.samples package has simple example of many XOM features.
This presentation: http://cafeconleche.org/slides/javapolis/xom/