> > I do not recommend generating code in a static language
> > from schemata. The fact of the matter is that is
> doesn't
> > really solve anything and creates a very brittle and
> > non-reusable code.
>
> At least the generated code is type safe and therefore
> less brittle than e.g. DOM code.

I guess you can define 'brittle code' any way you like but what I mean by brittle is that insignificant changes cause the code to break. DOM based code doesn't break when a new element is added to the schema or if an element's type is changed in a minor way e.g. it's length goes from 5 to 6.

In any event this isn't really the worst thing about JAXB code. The worst thing is that all the work to get the required information into useful places is basically hardcoded. I worked with fairly large JAXB base that was basically unmaintainable. With DOM you can at least write code that can retrieve elements from similar structures. With JAXB, you can have two schemata with the exact same address element structure but you must write the code to retrieve the the elements repeatedly because it creates wholly separate types for them. But I'm not advocating DOM. It's basically a straw man.

> > Basically you take the XML structure and create code
> that
> > is coupled to it. Now you will generally need to walk
> the
> > tree and extract the data for use in other places.
> This
> > means writing a bunch of code bound tightly to those
> > structures. In a nutshell you've just bound all your
> code
> > to a xml structure. Any change to the schema will
> require
> > regeneration of the code (if you use validation) even
> > where the changes are irrelevant.
>
> What you describe as disadvantages can also be seen as
> advantages. It depends on the application. When you need
> to create a XML message or store data in structured (XML)
> format JAXB certainly is a very convenient option
> (compared to e.g. DOM).

Convenient in what way? What could be more convenient than just populating Objects with data and using them? Walking trees with Java is a nightmare. The JAXB code I worked with looked like this:

if (greatgrandparent != null) {
   GrandParent grandparent = greatgrandparent.getChild();
 
   if (grandparent != null) {
       Parent parent = grandparent.getChild();
 
       if (parent != null) {
           Child child = parent.getChild();
       }
   }
}

But many more levels deep and over and over again. The only thing that's convenient about it is it allows you to avoid learning to use a proper XML toolset and do everything with Java.

> OTOH, if you want to recursively
> traverse the nodes or transform the XML file then DOM or
> XSLT may be better suited.

XPath and XSLT are good for these things but it has nothing to do with what I am talking about here.

> > A more effective strategy, one that JAXB 2 allows but
> > seems to be rarely used, is to create schemata for your
> > compiled types.
>
> This seems to put the cart before the horse. Moreover, the
> schema is often given because it's standardized.

You are definitely missing the point. The schema generated for the code is only used to map data into objects. The standardized schema doesn't go away.

I spent 2 years banging my head on JAXB generated classes. We got to the point where we'd go out of our way to avoid changing a schema because of all the work that was required to do it. Any slight modification would require generating new classes, writing a bunch of code and touching all kinds of tangential modules.

With the methodology I am advocating, you add any new elements to the classes that use them, regenerate the schemata and use any number of highly efficient XML tools to map the required data into the Object. You can map many different message formats to the same Objects making your code much more reusable. Generating classes from schemata seems like a good idea on the surface but is a fundamentally flawed approach. It would be workable in a dynamic language like Ruby or Python but in a static language it gets you nowhere. It creates a redundant mirror of the XML structures in code violating DRY among other principles of good design.

To make it clearer what I am talking about. We'd have say 6 different standardized schemata for a purchase order that we had to support with new ones added over time. In order to avoid generating 6 sets of classes and writing thousands of lines of Java to place those orders, we created a canonical schema for a purchase order. Then we took this and generated classes from it. Then we had about 1000 or so lines of code to put that canonical data into stable business Objects. Then we had another 1000 or so lines of code to write the data from the usable java Object back into the JAXB Object. The JAXB classes did nothing for us. In fact the made things harder because walking a tree in JAXB is extremely labor (read: code) intensive. Using the technique I am describing, the data goes from XML straight into the business objects and all the translation is done with the proper tools.

Pointers and ownership are independent of each other. XML is a hierarchical format, i.e. child nodes have only meaning in reference to (in context of) a parent node (except for the document node). Therefore it's quite 'natural' to let the parent nodes own their child nodes (the parent as 'container' for the child-ren). Of course, parent nodes may give access to their child nodes via pointers or iterators. But the lifetime of the child nodes can, and IMO should, be bound to the lifetime of the parents.

I don't understand what the original issue was then. The document tree is dynamically-allocated and returned as a pointer (wrapped into auto_ptr). Sub-nodes are owned by the tree and are returned as references.

Okay, "simple" was the wrong word.

Some situations require pointers. Some don't. If I were implementing the code manually, I would use pointers only where they were necessary. On the other hand, I don't mind that Code Synthesis uses a uniform mechanism for all child elements. I don't expect a tool to generate code that is identical to the code I would write manually.

Substitution groups and xsi:type require polymorphism, and therefore pointers (or references). Optional elements map cleanly to pointers. Some schemas describe cyclic data, and child elements must be pointers.