David Carver wrote:
> ... 
> The comments raised, really apply to all XML Databinding frameworks.  
> XMLBeans is one of the more compliant implementations out there, but
> regardless of which Databinding framework you use, you should ALWAYS
> validate the instance it generates.   The problem with data binding
> frameworks in general with XML is that people assume that because the
> classes were generated from a schema, that it will automatically
> generate the correct XML instance that is also valid against the
> schema.  This unfortunately isn't true, and JAXB 2.x exhibts the same
> problems that XMLBeans does.  The difference, is that XML Beans does
> correctly support more of the schema concepts than most other binding
> frameworks.

It's true that JAXB 2.x is also very sloppy on marshalling, but XMLBeans
is the only data binding approach I'm aware of which will unmarshal
without required elements present. Most other data binding frameworks
(JAXB 2.x aside), at least in the Java world, will throw an exception on
such basic errors as missing required elements or attributes when either
marshalling or unmarshalling.

One important point to keep in mind is that XMLBeans is not really a
data binding framework at all. Rather, it implements a data binding
facade on top of an XML memory image. That gives XMLBeans some unique
features, including full integration with DOM and XPath/XQuery, and
means that for general XML usage XMLBeans is a great tool. But for
applications that specifically want to do data binding XMLBeans is a
poor choice, with higher memory and processing overhead than most data
binding frameworks along with looser enforcement of document correctness.

As to validation, I strongly recommend that people use validation during
testing. In my experience, though, it's rarely used in production due to
the high overhead involved. In the longer run, the data binding
frameworks should be improved to the point where they *do* automatically
generate the correct XML instance that is also valid against the schema,
or at least make it much more difficult to read and write invalid
documents than at present.

  - Dennis

-- 
Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117