Re: [xml-dev] From Pox to Pojo

["Andrew Welch" <andrew.j.welch@gmail.com>]

On 11/10/2007, Pete Cordell <petexmldev@tech-know-ware.com> wrote:
> Well, we do an XML to C++ databinding tool (as you might have gathered from
> the sig!), so I'll give my views...
>
> I would say whether databinding is the right thing for a particular
> application depends very much on what the requirements are.
>
> I think databinding works best for the more data oriented applications.  In
> particular, mixed content is not very well supported.  If your data is
> generally data oriented, but has, say, a blob of XHTML in it via an xs:any
> specification, then I'd still say databinding is still appropriate.  You'd
> use databinding to access the XTHML blob, and then process that using some
> other technique (possibly some kind of third-party browser module).
>
> Also the more your XML data is a means to an end rather than an end in
> itself, then the more likely databinding is going to be a good fit.  By that
> I mean the more you can treat the XML side of things as a black box for your
> application, the more databinding will be good for you.  That doesn't mean
> that unmarshalling an XML instance into objects, twiddling them and then
> marshalling them out again isn't appropriate.  It's just that if that is
> your entire reason for existence, then it might be considered a bit lazy and
> you could probably do a more efficient job using something like XSLT or SAX.
> (Although - I would do the lazy route just because I am more familiar with
> it and already have all the tools!)
>
> If your XML data is very large (where 'very large' depends on your system)
> then databinding might not be appropriate.  This is because databinding
> results in the entire XML instance being represented in memory.  I've never
> done any tests to get an idea of how the size of the XML instance compares
> with the amount of system memory consumed, but I would expect the consumed
> system memory to be less.
>
> Databinding is also very handy if your data persists in the application for
> some time, and a number of different code modules dip in and out of it (such
> as configuration data).

Thanks for the reply Pete, to be honest I was losing faith in this
list after such an on-topic subject recevied no replies...

Anyway, I've gone down the hand coded route because even though it's
basic data centric XML, I needed a bit more behaviour from the
enumerations that I wasn't getting from the generated code.  For
example given this:

<xs:simpleType name="item">
  <xs:restriction base="xs:string">
    <xs:enumeration value="009">
      <xs:annotation>
        <xs:documentation>Not Applicable</xs:documentation>

My ideal enum is something like:

Item.Not_Applicable

which makes the code most readable, and the value and the textual
description are availabe through methods like Item.code() and
Item.desc()

Instead I get

Item.INT_X_009

which is understandable given the enums value, and its understandable
not to get the textual description available, but it just means the
code that uses the enum isn't going to be as good, and I'd have to
store/access the description in some other way.

I suppose i could write an adapter layer, but it doesn't seem worth it
in this particular case.

On the plus side, an interesting thing with XMLBeans is that you can
use XQuery to select the nodes after they've been parsed into pojos:
http://xmlbeans.apache.org/docs/2.0.0/guide/conSelectingXMLwithXQueryPathXPath.html

I've not had time to try this out but it looks interesting...


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