XML Tool is a Java library to help developers using XML document. You can build new documents, load existing documents, and execute all sorts of operations onto: delete, renaming, adding tags, attributes, text, data, namespaces, ... Navigation by XPath is also supported. Since it uses the Fluent Interface pattern, you don't have to know about plenty of classes, but just one: XMLDoc. From there, you can just use your IDE's code completion to check for available methods and call them consecutively. You can download / checkout XML Tool from http://code.google.com/p/xmltool/

Interesting, though maybe too close to regular DOM for my liking. When it comes to building documents, I wrote a Groovy script that takes an XSD and produces a fluent API for constructing documents conforming to it. Element/attribute names map to method calls on the builder. XML construction with intellisense! Good luck Kit

I was thinking of doing the same thing after writing a small, type-safe, XHTML builder in Java. Any code you can make available?

I'll need to dig it out. Pls email me at kdavies -at- kidare -dot- com . Regards Kit

Have you seen the XML thing Anders Noras (the guy who started Quare) posted on his blog? http://andersnoras.com/blogs/anoras/archive/2007/04/25/xml-dsl-for-java-1-5.aspx Looks more like XML than anything else.

Hi, Yes i read his blog. He took another track: a DSL one. Like Hamcrest, you have to import all static methods of a class and chain method calls, and also know what method is available to use it. This is quite different from a the fluent interface way: it is much more like Google Guice Binder for example, where you do not have to know about which method exist. Both are useful. To my mind, a the big difference is that a DSL provides better reading for a specific need, and FI provides better intuitive use of something.

...is somewhat overused. Take the example code (copied below and assuming it is correct) where the call to .gotoRoot().addTag("other:foo") apparently places you at the level of the Tag - otherwise the goto Root method() would be meaningless - but it returns an XMLDocument!. The outcome thus, is an XML Document with a state pointer asscociated with it. XMLDocument doc = XMLDoc.newDocument() .addDefaultNamespace("http://www.w3.org/2002/06/xhtml2/") .addNamespace("wicket", "http://wicket.sourceforge.net/wicket-1.0") .addRoot("html") .addTag("wicket:border") .gotoRoot().addTag("head") .addNamespace("other", "http://other-ns.com") .gotoRoot().addTag("other:foo");

Sorry for a shameless plug, but I have a similar project called TXW (https://txw.dev.java.net/). It can be used to generate any well-formed document, but it also comes with a compiler so that you can compile a schema into interfaces for better typesafety.

This looks like something i can use on a project. Is its 1.5 compatible?

Looks like most xml content output variants basically just want to replicate inefficient bulky DOM with some convenience sugar. This does not make sense to me -- if you essentially call output methods in sequence, why not take use of it and keep things light-weight and fast? Actual output using SAX or Stax has similar speedup ratio to parsing; that is, it is 3-5x faster; and memory usage is bounded as opposed to relative to output size. So here's an alternate idea, in form of a shameless plug: lean output (and input...) is exactly what StaxMate (http://staxmate.codehaus.org) does. You do build content using output objects, similar to node objects. But the output goes straight to the underlying streaming xml writer (unless you explicitly want to buffer things via buffered output objects, for out-of-order output). This has been tested to perform at level very much like "raw" Stax xml writing, but with more compact and convenient code.