This is mini review of "A Design Review of JDOM ( A Conversation with Elliotte Rusty Harold, Part III) ".

Let see how Xml Pull Builder a.k.a. XB1 (for more details on XB1 see its home page) compares to JDOM based on points raised in article.

A Short History of JDOM

Before we do this few word about XB1. XmlPull Builder Version 1 a.k.a. XB1 is lightweight document object model to represent XML tree that is implemented on to Common API for XML Pull Parsing and alpha version is in XPP3/MXP1.

JDOM Offers Many Convenience Methods

XB1 is currently rather modest API and do not have lot of methods (except for obvious overloading of methods) and that makes API quite simple (at least for now).

JDOM Allows Malformed Documents

XB1 implementation also allows creation of malformed documents or let put it this way: the implementation does not do extensive checks but XB1 API allows implementations that will do those checks (XB1 API is composed of interfaces). BTW: example with control characters is not good as XML allows to have control characters but escaped as numerical entities AFAIR ...

JDOM Ignores Setter Method Conventions

I do not see problem here: JDOM is not Java Bean and chaining methods may be sometimes convenient (but should not be overused). This looks like rather weak complaint ...

JDOM Uses Java Collections

XB1 goes one step even further and it uses Generics for even more natural iterators than mentioned NodeList (currently moving to use future java.lang SimpleIterator interface so idiomatic for(XmlElement el: node.elements()) will work in JDK 1.5) .

JDOM Uses Too Many Checked Exceptions

XB1 has only one exception (at least for now) and it is runtime exception for all reasons mentioned in the article and i woould add one more reason: RuntimeException makes it easier to integrate XB1 into existing code.

Will JDOM Remain Class-Based?

I agree that interface based API is more versatile as it allows to abstract form implementation and allow creating XML tree models directly from other data sources that XML event stream from parser (like databases)

Conclusion

I was disappointed that XPath integration (and good performance of it) was not mentioned. Also I would like to see some tests that compared memory footprint and how easy is to build partial tree: this is very easy with XML pull parsing but quite difficult with push parsing (in SAX it requires provide way to overwrite endElement() callback and in general is as much fun as writing SOAP deserializer with SAX). And as far as future of XML Tree APIs: I would like to see how easy is to annotate XML infoset items with additional information (needs for it emerges with data bindings and PSVI)

But after all what makes and breaks APIs is how programmers feel about them, and I feel good about XB1 when I am using it (nothing to do with the fact that I am author of it of course ..)

Xydra is a library that uses servlet to provide XHTML based WSDL invoker. Xydra servlet takes WSDL with XML Schema complex types as input, generates XHTML form to allow user to fill content of input message, gathers submitted input values and converts form name-value pairs into XML message that is sent it to Web Service and then finally displays result message.

One could ask: there are other WSDL invokers so what makes Xydra unique? Here is couple reasons:

• Xydra has pluggable data model and currently two backend to represent form and XML message content One is traditional name-value pairs that are structured into tree (called TreePath) and second that is based on Protege engine to use ontology describing web service to allow more reach constraints and relationship validation (called OntoBrew).
• It is very easy to customize Xydra look and feel: just save auto-generated XHTML page, modify it to your needs and tell Xydra to use this XHTML page as template. What makes it really easy is that template is a regular XHTML page that is used by Xydra processing engine (unsurprisingly called Diesel) to annotate it with runtime information.
• Xydra support complex types and generate nice XHTML form UI for arbitrarily nested XHTML forms.
• You get source code so you can improve it :-)

Sample installation is available online to test drive Xydra. It is open source so anybody can play with it, improve it, and give us feedback, patches are gladly accepted, we may even fix some bugs when reported (good bug report that contains all information necessary to reproduce problem and/or unit test greatly increases chances of getting problem fixed ...)

(...)Ok, so let's start to talk about the product: It is about SOAP Services. Actually, they still call it Web Services but in fact, it has nothing to do with the web at all. It is only about SOAP anymore - and it is only about SOAP as a framing format anymore. Frankly, I think that this is a very good thing: using HTTP in your mission critical applications might not be the best idea. Wouldn't it be way cooler if you could just take an XML document, wrap it in a SOAP envelope and send it over whatever reliable protocol you like? While still using all WS-* and GXA specifications?

this desription of WSE2 sounds like what WSIF except that WSIF has support for industry standards such as CORBA/IIOP and does not require to send SOAP envlopes.

However the problem with WSIF that it is only client side ...

As soon as Echo (aka Pie) is well defined microBlog will add support for it.

Google found for me this interesting report (local copy) on performance of XML object models.

As this document is written to promote commercial product X-Fetch Performer unfortunately details of tests (machines, JVM, code versions) or at minimum source code for tests to verify results is not available and that renders those results very unreliable ...

"OK, you're up," the Genie says to the manager. The manager says, "I want those two back in the office after lunch."

Moral of the story: Always let your boss have the first say.

• we need simple (and working) easy to use workflow engine for BPEL4WS that works on grid (for example on top of CoG API but workflow engine hides that it uses any particular grid toolkit ...).
• WSDL as ultimate URL - but how to find correct WSDL needs for permanent URL and in OGSA it is GSH ...
• different computing paradigms: Java is to java specific so now we replace Java with XML and re-implement Jini -> Gird and Web Services ...
• not to forget (note to myself): why we need components?
  
  reusability and etc is nice but why they are really needed is because only few grid users are grid programmers or computing scientist (TODO: check term) instead we need to provide generic tools such as components (and XCAT!)
• XSpaces needs official release, badly! (another note to myself)
• Noted observation: Grid Spam is grid application that sends (XML) messages/events that are automatically converted into emails ...
• PC + Management = Managewoment ???
• new product besides eCluster, eUtility, eDisaster in IBM family is now eWeSolveYurProblemsForSmallFee <blink> <blink> ;-)
• heard on Oprah: nobody talks about what is happening after the wedding? yeah we need to explore this space too ...

XML is not about APIs it is about processing XML. if XML was finished and there was no work on standards (DOM3 comes to mind) and implementations were finished and abandoned (Xerces2, Xalan etc.) than maybe it would make sense ...

actually that brings another point: java badly needs library (JAR) dependency mechanism in use right now ...

what is between DOM and SAX?

of course KHR, KHS, LHR or LHS

by looking up ASCII codes D=68 S=83 so average is 75.5= K=75 or L=76, then second letters O=79 A=65 so average 72=H and finally M=77 X=88 so average 82.5 R=82 or S=83 :-)

APIs that are doing essentially the same things are bad ...

Corba: why PL independent

XML integration ...

components as Web Services will help life easier ...

cost of monolithic applications ... what is API

XML schemas (what is target)

SOAP acronym ... no Simple ... no Object ... so what is left ...

CORBA has no abstract protocol

too much abstraction is not good ...

how to keep close to XML infoset?

How to combine best of SAX and DOM when working on SOAP

motivation DOM API (or one of its alternatives) is easier to use for document/literal encoding but streaming is essential for good performance ...

solution: two different modes of operation

• when constructing node tree (streaming)
• walking already constructed node tree

one goal: have uniform API for both cases (stream is parsed as much as needed to walk tree)

second goal: expose enough information in API so app can control tree creation skipping parts of it or using XmlPullParser directly (no tree nodes created) parts of tree can be detached for later GC

handling fragments transparently add all ancestro namespace-prefix declarations

        XmlPullNode
                isFinished()
                finishParsing()
                XmlPullParser asPullParser
                XmlPullNodeWalker asNodeWalker
        XmlPullNodeWalker
                Object nextNode(),
                Object nextNodeChild(),
                String nextNodeText(),
                XmlPullNode nextNodeTag()
                XmlPullParser asPullParser();

DOM working as front partial tree - mirrors what is in XmlPullNode however operations directly on XmlPullNode are _not_ mirrored to DOM!!!

Possibly related: PullDOM http://www.prescod.net/python/pulldom.html