[jdom-interest] Content as a Text Node (was JDOM JSR)

[Trimmer, Todd]

> From: philip.nelson at omniresources.com
> [mailto:philip.nelson at omniresources.com]
> Sent: Monday, May 21, 2001 1:02 PM
> To: todd.trimmer at trizetto.com; jdom-interest at jdom.org
> Subject: RE: [jdom-interest] Content as a Text Node (was JDOM JSR)

<snip>

> > deal was. At this point, anyone who vehemently believes 
> > Attribute should be
> > a  Node can only persuade me by sumbitting real code to show why.
> > 
> Here is a great  example of my point.  You may have no reason 
> to include
> attributes.  I may want that (give me a reference to an 
> instance containing
> text "foo").  If the built in version doesn't include it, I 
> have to subclass
> anyway.  I may as well subclass with the node interface I 
> actually need.
> Then, my iterator method can vary too.  I can allow the option of an
> iterator based on an xpath expression or with xlink paths 
> followed or who
> knows what.


XPath support and a Node interface can be mutually exclusive goals. Look at
Bob McWhirter's XPath support. Even if an attribute is not a Node, you can
still use an expression like "@*" to retrieve a list of attributes under the
current element.

So while a Node that does not include Attribute as a subclass does not
satisfy every possible extension of JDOM conceivable, one can get very far
with it. Again, several XML technolgies that are used extensively in the
field do not consider Attributes to be nodes. And these technologies, in
turn, have also been happily extended.

Attributes being treated differently isn't so bad. Look at the
NamespaceCountVisitor I included in my source code posting. Even though
Attribute does not have a acceptVisitor(Visitor) (since it's not a Node), it
wasn't too difficult to call NamespaceCountVisitor.visitAttribute(Attribute)
inside of an iteration of an Element's attributes inside
NamespaceCountVisitor.visitElement(Element).

After seeing how easy this was to do, I felt greatly justified in not making
Attribute a node. My NamespaceCountVisitor still recorded a count of every
namespace everywhere in the document with little fuss.

Sure, you COULD have Attribute be a Node, with goDown() return null (like
Text and CDATA do) and goUp() returning the Element it is attached to, but
an iterator or visitor would never be able to get down to it from another
Node. So it would be misleading to say an iterator would generically recurse
down the whole tree, attributes included -- the attributes would be skipped
over. Ok, now let's say to get around this, Attributes are included in the
list returned by Element goDown(). Where in the list do they go? Before the
content objects? After? Interspersed?


> Your goUp is another example.  The base classes have 
> getParent which returns
> Element.  goUp returns NodeX.  If I wanted to extend my node 
> interface and
> use it without casting, goUp should now return my node 
> classes but can't
> because of signature problems, so now I have getParent, goUp 
> and say goUpX.
> What have I gained by having goUp?  My goUpX could have 
> called getParent
> itself.


That's like complaining you subclassed java.lang.Object and now
java.util.List.get(int) won't return your new class. I don't understand why
one would expect to be able to use an added method of any subclass without
having to cast it to that subclass first. Once you start CARING about which
particular flavor a base class is, you have cast it.

If no one can come with a good reason for any content type to return
anything BUT an Element when traversing upwards, then we can change goUp()
to return Element. I have no qualms about Document not being a Node -- I can
see it being used either way. I leave it to the community as a whole to
decide that one. There is no big difference for me between
traverseDocument(document) and traverseDocument(document.getRootElement()).


Todd Trimmer