On Wed, 2010-04-28 at 16:56 +0100, Mark McLoughlin wrote:
This was going to turn out like:
<storageDetails>
<NfsSpecific>
<host>172.31.0.6</host>
<path>/exports/RHEV/images/0</path>
</NfsSpecific>
</storageDetails>
right?
Yeah, the idea was to encode the storage type _implicitly_ in the choice
of NFS- or iSCI-specific storage details. As opposed to using a separate
<type> element (or attribute) as you've done below.
Not because the XML is any nicer (it isn't!). But more to remove one
degree of freedom from a validation point of view. Having a separate
type indicator raises the possibility of a mismatch between the type set
and the actual details provided.
I was aiming for something more like:
<storage>
<type>NFS</type>
<path>/exports/RHEV/images/0</path>
<host>172.31.0.6</host>
</storage>
(whether the type should be an element or attribute is debatable)
[...]
I'm not loving how this turns out in Java - there's no safety
about
storage type specific parameters being used with the correct type.
I think in JAXB 2.2 the generated setter is supposed to be a single
this-or-that proposition, as opposed to a separate setter per choice.
Are you seeing the latter in the generated code?
But either way, I don't we're going to get codegen'd type-safety
relating the choice to a corresponding value in a separate element (the
<type> in this case). Probably need a schematron rule or some-such to
achieve that.
Cheers,
Eoghan