On 09/10/2007, Dennis Sosnoski <dms@s...> wrote:
> Data binding tools generally have fairly primitive support for schema.
> Most treat unions, for instance, as just strings, and nested compositors
> with maxOccurs > 1 will often result in an API that has an array of
> undifferentiated element components (perhaps with a parallel array of
> type codes) without regard to the ordering or occurs restrictions given
> in the schema definition. So you're best off sticking with fairly simple
> constructs, and the salami slice style is a good match in that regard.

Can't you validate the XML as well as unmarshall it?  Seems odd...

In my particular case the XML is very straightforward and very
de-normalised, so writing the schema for it was trivial.  I considered
suggesting "improvments" to the XML but that would mean introducing
co-occurance constraints...


> XMLBeans does a better job than most data binding frameworks of exposing
> the schema model in the generated code, but on the other hand it doesn't
> enforce most aspects unless you actually use validation. It's very easy
> with XMLBeans to generate invalid XML documents by forgetting to set a
> required value, for instance - XMLBeans will happily marshal whatever
> you do set, without any complaint about the missing values (and will
> also ignore missing required values when unmarshalling, for that
> matter). Most other data binding frameworks would throw an exception if
> you're missing a required value on either marshalling or unmarshalling.

Thanks for the reply, I was under the impression that XMLBeans was
really good (from reading around) but you've definitely given it a
negative slant.  I don't know enough about it yet but from my naive
point of view the problems you've raised seem like they could [or
should be able to] be solved just be turning on a switch...

I was going to ask about general pox to pojo but I'll raise a separate post.

thanks
-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/