Les,
Actually I was not arguing about the usefulness of a tree model. I was just
trying to point out that such a feature may be redundant and overstretched
for JAXB. First, the object hierarchy created by xjc maintains the tree structure of the orginal XML document. So you can traverse the object hierarchy to search for or manipulate objects. Second, using application-specific manipulation functions will be more efficient than using generic
tree functions since your application has the complete knowledge of the object hierarchy. Third, creating and maintaining a tree is going to be
very very expensive, and in JAXB's case, the effort is even more than
SAX/DOM because you have to make the tree and your object hierarchy in sync.
I guess without a specific use case, it is hard to see the added values of
a tree model interface in JAXB. The most common applications of using JAXB
I've seen is creating configuration objects from XML files. This type of
apps doesn't require tree-manipulation/search functions. What
type of JAXB apps are you thinking of?
Nevertheless, I don't believe the current JAXB spec is perfect. I think
one major limitation of applying JAXB in applications is the dependency of
object APIs on XML schema. Maybe a tree model interface is indeed necessary in order to decouple such dependencies. But this is certainly
out of scope for this discussion.
Thanks!
ND
On Tue, 28 Jan 2003 16:50:51 +0000, Les Hazlewood <les_at_hazlewood.com> wrote:
>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