[jdom-interest] Common interfaces..

[Kenworthy, Edward]

>- 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.

Perhaps I am missing something but surely separation of the view from the
model dictates that it should be ?

+Certainly "How do 
+I get the string form of an Element/Attribute/Comment/Document/etc." 
+is a FAQ

toString() is already implemented isn't it ? I've certainly seen Element
stringify itself.

-----Original Message-----
From: Elliotte Rusty Harold [mailto:elharo at metalab.unc.edu]
Sent: 04 May 2001 03:45
To: jdom-interest at jdom.org
Subject: RE: [jdom-interest] Common interfaces..


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.
>"foo/bar/@name")
>>  * 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?

Node obviously.

>- 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 
traversal capabilities.

>- Most importantly, JDOM's use of Strings throws a wrench into any node
>interface plan.
>

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 
>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.

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/     |
+----------------------------------+---------------------------------+
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com