[jdom-interest] Ideas for API changes

[philip.nelson at omniresources.com]

Is it worth it for me to go back and read the messages related to this item
from the archives?  I guess I am have trouble understanding what has
changed.  This was discussed at incredible length in the past and this and a
couple of other issues basically caused a split that sent some very active
developers away.  The reasons seemed sound at the time but I wasn't very
involved at then and didn't follow the arguments in detail.

Here are some other things I don't understand, in part because I haven't
actually done some of these things myself.

- Tree walking was always considered to be outside the core meaning that it
would have to be built on the methods of the specific objects.  I can
imagine the benefit of a Node is that you could walk by always asking for
children and parents in the same way.  But is the use case strong enough to
make a comment, pi, attribute etc have a getMixedContent type of method?
The answer has always been no.
- when using the Collections api, would I end up first casting to Node and
then to a specific class anyway? Or does this mean you want a collection
framework that wouldn't use Object as well?  This to me seems to be a change
to what JDOM *is* instead of how JDOM works.
- since Bob doesn't see Node as useful for the XPath api, does that
influence this much?  Wouldn't a fully implemented xpath remove a fair
number of traversal use cases?  Could we just move up the timetable for that
instead?
- Brett, could you comment on why serialization forces you to consider
XMLOutputter(object)? I am using serialization but I have never encountered
this issue.
- moving to a Node based implementation seems to be moving closer to what
DOM is and as some of you know, I have always been uncomfortable with
treading on what DOM is.  If for no other reason, we can't hope to keep up
with all of those paid developers ;^).  Then there's the standards issue.  I
could go on.

On first glance, I think Jason has hit my feelings perfectly.  The
commonality between the different parts of JDOM is minor compared to the
differences.  These changes would appear to indicate a *large* rewrite, not
only of JDOM but of many classes based on JDOM (like mine).  The benefit
would have to be equally large IMHO and I don't see it.

BTW, I had hoped a tree walker could be based on a decorator rather than a
subclass.  Then folks could make the Node/Item etc. whatever they wanted.
Makes more sense if tree walking is not a real common case.