Damon Maria wrote:
> The EA version of the JAXB binding schema had <interface>s that allowed
> for the
> polymorphic use of elements (for example: a choice group of elements
> could be
> treated as a collection of an interface if each of the choice elements was
> listed as a member of the <interface>). This has proved most useful to
> me in the
> work I've done with the EA version.
>
> When I heard about the new version of JAXB mapping schema types to
> interfaces I
> thought this sounded like the prefect answer to the messiness of the
> <interface>
> definition. Using xsi:type or subsitutionGroups this could all be specified
> using schema mechanisims without having to list them explicitly in the
> binding
> schema. And even better, through <xsd:import> we could add new
> sub-interfaces/classes to these types without modifing the base schema
> or bindings.
>
> How come then the 0.75 spec states that xsi:type and substitutionGroup
> are not
> required to be supported by a JAXB implementation - as this IMHO seems
> to be a
> fundamental feature and an obvious use of the type hierarchy that JAXB
> builds
> from XML schemas. What use is mapping schema types to java interfaces if we
> can't make use of them in our schemas?
Required support for type substitution and element substitution will be
considered in the next release of JAXB. In order to deliver the first
version in a timely fashion, some of the extensive XML Schema
specification had to be subsetted out of the first version.
-Joe Fialli, Sun Microsystems
>
> regards,
> Damon.
--