Nick Duan writes:
> I think the fundamental issue regarding whether a TreeModel should be included in JAXB is not performance, but what JAXB is really designed for. Conceptually, adding a tree like interface to JAXB is the same as exposing the DOM interface to your application, and that is the first thing JAXB was intended to eliminate.
I disagree. JAXB stands for Java Architecture for XML BINDING.
The primary purpose of JAXB is to provide a clean implementation of binding
an XML Schema to Java data objects with the smallest amount of effort for
the Java developer. While DOM details are removed from the programmer and
is something of importance, this is only a benefit of JAXB (albeit a big
one), not the core reasoning behind JAXB.
Again, conforming to some TreeModel would not change how JAXB is used, and
only enhances how it MAY be used. If you don't need the functionality, you
don't have to use it, and JAXB would still work as expected.
If a TreeModel interface is not included in future releases, I will
understand why. This just requires more effort on the developer who might
need tree-like functionality after already going through the unmarshalling
process (without having to create another different sax/dom tree for things
like pre/post/in order searches and other tree functions). I'd just hate to
see multitudes of developers wasting their time on such tasks if a
significant number of them needed it and the JAXB framework could very
easily implement it. But other than myself, I have no idea how many would
like or need such functionality.
Les Hazlewood