Create Node interface, implement it in Attribute and Content

[ttaylorr]

No description provided.

[rolfl]

Node is a concept that was rejected from JDOM at the very beginning. Certainly, Attributes are not nodes. Can you try to describe why it is that you need a single base type for content, and why the current API does not support it?

[ttaylorr]

The way I see it, Element and Attribute are both containers for data. Element contains data like this: <some-element>data</some-element> and Attribute contains data like this <some-element attr="data"/>. Currently there is no common interface between the two of them that allows for easy data-access (ideally node.getValue()).

The main problem that this introduces is that to parse numbers or booleans or anything out of these two "disperate" object types requires 2x the code.

[tonybruess]

@ttaylorr @rolfl any further thought put towards this PR?

[rolfl]

I have looked through this proposal further. I am rejecting it for the following reasons:

1. Node is a word/name that has a hugely overloaaded meaning, and the predominant meaning for me is related to XML nodes, one of which is the Document, and this Node you introduce does not apply to the Document, so the name 'lies'.
2. Node is also heavily used in the DOM implementation, where everything is a Node, and it's not the model we have in JDOM.
3. One of the benefits of JDOM is that when dealing with lists of content, you have lists of Attribute, or Element, etc. List<Element>. I am struggling to see a use case where people will have a List of List<Node>. Can you give me an (realistic) example where someone would want to conflate all their attributes and elements in to one list, where they ddon't know what type it is, but they do know that there is not a Document in there too (i.e. why is a List<Node> more useful than a List<Content>)?

I know it has been a long time since you posted the pull request, but I cannot see a circumstance where this new level of abstraction adds value.