[jdom-interest] Element Reference from Attribute

[Jason Hunter]

> 1. Everything needs to know its parent. I don't really care if that
> adds 4 bytes to each object.

This would make moving objects more consistent as well, since it would
be easy to detect if the same object existed at two points in a tree and
disallow that add.  The downsides I see are 4 extra bytes per object,
and extra processing to manage parents.

Can you give the XInclude use case for where knowing the parent helps?

> 2. Using Strings instead of a Text class is extremely inconvenient.

With a design so that getMixedContent() returned a list including node
of type Text but getText(), or some such method, still returned a
String?  It's a hard requirement that you can get a String from an
Element.

Is the use case here the knowledge of parent issue?

> 3. A Node interface or superclass would be a good thing.

Could you provide more detail about how you would design it?

> However, there are still some aspects of JDOM that have proven to be
> useful or at least convenient in working with XInclude:
> 
> 1. Classes instead of interfaces

I agree, the list of reasons classes are better keep growing.

> 2. Constructors instead of factories

Yes.

> 3. Following Java coding conventions

Allelujah!

> 4. Nodes that don't belong to any document are very useful.

Agreed.  And only possible due to #1.  I'm curious, why has this been
handy for an XInclude processor?

> On an unrelated note, I've also come to the conclusion that Java does
> need friend functions. There are a lot of cases where the
> org.jdom.input package and prg.jdom.output package classes have
> legitimate reasons to know more about the objects in org.jdom than
> are exposed through the public interface, but I'm not sure there's
> anything we can do to fix that. (Does anyone know a good design
> pattern that substitutes for friend functions?)

I agree.  An org.jdom.translate package for XSLT might need special
rights as well.

-jh-