[jdom-interest] Common interfaces..

[Rosen, Alex]

> A few ideas for methods could be...
>
> * getParent()
> * getDocument()
> * accept(Visitor)
> * return itself as a snippet of XML text.
> * return the XPath 'string-value' of the node as per the XPath spec.
> * return the XPath expression required to navigate to the node. (e.g.
"foo/bar/@name")
> * evaluate XPath expressions relative to the node.

This is a good list - I didn't think there'd be that many. There are a few
problems making this work in JDOM, though:

- Currently, the XML outputting capability is in a separate class, and the JDOM
"nodes" don't know anything about it.
- Currently, the XPath support is in a whole separate project, and the JDOM
"nodes" don't know anything about it.
- Putting XPath in the interface would require that Attributes are nodes but
Entities and DocTypes aren't. Some people want a different list of what's a
node and what isn't.
- What's the return type of getParent()? Is it Object, or is there a second
interface for something that can be either a Document or an Element?
- I'm not sure about the utility of the Visitor pattern - it seems overly
complicated for what it's trying to do, especially with the pushes and pops
that Paul mentioned. I think there are much more straightforward ways of
walking a tree, that are easier to understand.
- Most importantly, JDOM's use of Strings throws a wrench into any node
interface plan.

A more general question is, when would this interface be useful? In practical
terms, it seems to me that an interface is only useful if there are times when
(1) you can do useful work just by calling methods on that interface, w/o
having to cast, and (2) you don't care what type of object you're dealing with.
Otherwise, your interface is no better than just using Object. For example,
List fulfills these requirements (you usually don't care if it's an ArrayList
or a LinkedList). For graphical components, you often do care about the type,
but during painting (for example), you don't.

I theorize that you *always* care about the type of an XML object you're
working with. In any real world example, you *never* want to treat an Element
the same as an Attribute or Comment or ProcessingInstruction. They are just
used for completely different things. Of course, this in and of itself doesn't
mean we shouldn't use this interface - just because I can't think of an
example, doesn't mean that someone out there doesn't have a good reason for
this. But, I think that there would be a number of ugly things we'd have to do
to the JDOM API to work around the above problems (especially the String
problem), so I think we'd really have to believe that this has substantial
real-world uses before we do it, and not just hope that it does.

Alex