[jdom-interest] API Inertia

[Rosen, Alex]

> I think it should be "This is our last
> chance to make this API what it should be, so big or small,
> let's change now while we can."

I agree completely. We won't get a second chance to get it right.

> After over two years of being a Java and XML guy, I think we NEED a
> commonality in JDOM. This idea that it isn't any better is not valid; I'm not
> saying it's better or worse than the current API. I'm saying if I could go
back
> and do JDOM again, there's no way in the world I'd do it without this.

Huh? You've completely lost me here. We should only do things if they make JDOM
better, no?

> It makes too many things a pain. Traversing a tree, which is a 50 line
example
> in DOM (weird structures and all) becomes a tremendous pain in JDOM; I
> know, because I'm writing the chapters on it.

I haven't tried it in either one, but... why would a Node interface help?
Assuming you actually want to do something useful with each visited node, why
is getting a Node any better than getting an Object? It seems clear that the
Node interface would have few (if any!) methods on it, so you'll probably need
to cast anyway.

Also - I would imagine that a lot of tree traversing code only cares about
Elements, no? Node would be irrelevent here. And, if you didn't just care about
Elements, which things would you care about? Would you want to visit Entities?
Attributes? CDATAs? Strings? It's not clear what should be a Node and what
shouldn't.

> Additionally, with SOAP and things like that, I
> really am annoyed in having to get an "Object" back over the
> wire. I can't count on it being something that I can feed to, say,
> XMLOutputter. How nice would it be to pass a Node, or Item, or whatever, to
the
> print() method of XMLOutputter? Pretty darn sweet.

Again, which classes should be Nodes? XMLOutputter can output an Entity, but an
entity doesn't have an XPath value, AFAIK, so the people that want Node for
XMLOutputter and the people that want it for getValue() are incompatible.
There's no single list of what should be a Node and what shouldn't. Instead,
you'd need a ton of interfaces to satisfy everyone:

CanBeOutput
HasXPathValue
Parent (e.g. Document and Element)
DocumentChild (e.g. DocType and Element, but not Attribute)
ElementChild (e.g. Attribute and Element, but not DocType)
etc...

And, you'd still have to handle String specially everywhere.

I agree with Jason, that the Node idea is seductive, but when you think about
it hard enough, it causes more problems than it solves. XML objects have too
many subtle dissimilarities to make a common interface work.

Alex Rosen
SilverStream Software