[jdom-interest] Common interfaces..
Elliotte Rusty Harold
elharo at metalab.unc.edu
Thu May 3 19:45:26 PDT 2001
At 2:50 PM -0400 5/3/01, Rosen, Alex wrote:
>> 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.
>> * evaluate XPath expressions relative to the node.
This leaves out a public clone method as well as equals(), hashCode()
and toString() which could be added if we made this an abstract class
instead of an interface so this is not an exhaustive list. Right now
I'm leaning toward an abstract class since it lets us do more, and
currently all the node classes just extend Object anyway.
>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 this is true, but it doesn't have to be. Certainly "How do
I get the string form of an Element/Attribute/Comment/Document/etc."
is a FAQ
>- Currently, the XPath support is in a whole separate project, and the JDOM
>"nodes" don't know anything about it.
But they could easily do so and it would be useful for them to do so.
Getting the XPath value does not require a full XPath implementation,
and it gives you a very straight-forward, well-defined, intuitive way
to get just the text of any JDOM thing. I agree that returning an
XPath expression is probably not something we want here.
>- 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.
DocTypes can still be nodes. So can unresolved entities. I think
that's the way we're moving.
>- 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.
Perhaps. I've been reading up on Visitor and so far it seems to me
like it requires a common interface such as Node rather than
replacing it. It doesn't provide tree-traversal capabilities, just
gives you a way to add functionality once you already have tree
>- Most importantly, JDOM's use of Strings throws a wrench into any node
Yes, and I'm on record as favoring a non-String Text class. But even
if we don't do this, there are a lot of applications that don't need
to look at the Text nodes as more than the value of an element.
>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
>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.
Any time you're cutting and pasting one part of an XML document to
another, or including it or embedding it or otherwise moving it
around, you generally want to treat element, comments, processing
instructions, and strings exactly the same. This happens in XInclude.
It happens in XSLT. It happens in a lot of custom applications. And
sometimes when searching a document for content you want to treat
element, comments, processing instructions, and attributes exactly
the same so you can search each one, not always but it is done.
>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.
The reason I'm so adamant about the need for a Node interface or
abstract base class is that I've been working on a system that's MUCH
easier to implement in DOM precisely because of the node interfaces
and clean tree model DOM provides. JDOM is supposed to be easier for
Java programmers to use than JDOM, but on my XInclude processor that
is definitively not true. I can already see that when my project
moves into XPointer soon, DOM's going to be easier to use for that
part of the project as well. The same is true in XPath and a number
of other schemas. I suspect Brett's noticed that his projects would
go easier with a clean tree model based on nodes as well, which is
why he's now in favor of the node interface.
There are many demonstrable systems Node would help a lot. Just
because your problems couldn't use this doesn't mean others can't. I
certainly see a lot of developers in this thread looking at a very
small part of the XML world and claiming that because JDOM works
there, it's adequate for anything anybody might ever need. XML is
bigger and more complex than a lot of people realize.
Keep in mind that if Node doesn't help you it costs you nothing. You
can still use the concrete subclasses just like you do today and
ignore Node completely. Those of us who need it can use it without
getting in your way.
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
| The XML Bible (IDG Books, 1999) |
| http://metalab.unc.edu/xml/books/bible/ |
| http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/ |
| Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ |
| Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ |
More information about the jdom-interest