On 6/27/2009 11:19 AM, Wolfgang Laun wrote:
> On Fri, Jun 26, 2009 at 11:57 PM, Lucas Madar <lucas_at_mcsnw.com
> <mailto:lucas_at_mcsnw.com>> wrote:
>
> Hello,
>
> I have a class hierarchy that's generated like this (without the
> treatRestrictionLikeNewType set):
>
> class BaseEntity
> class BaseSeries extends BaseEntity
> class MeasurementSeries extends BaseSeries
>
> In xsd, BaseSeries is an extension on BaseEntity, and
> MeasurementSeries is a restriction on BaseEntity.
>
>
> The XSD contains, in the definition of measurementSeries:
> <xs:restriction base="baseSeries">; so why should this be a
> restriction on *BaseEntity*
Sorry, this was a typo - it was meant to demonstrate a class hierarchy
from BaseEntity -> BaseSeries -> MeasurementSeries.
>
>
> With treatRestrictionLikeNewType set, I would expect to get
> MeasurementSeries extends BaseEntity, since it's not really
> involved in the restriction, but instead I get an isolated class.
> It's unfortunate that there's no clean way to do this in xsd that
> translates nicely into java.
>
>
> The generated classes, as you describe them, seem to be an accurate
> binding of the schema.
>
Now that I think about it more in depth, I guess I agree with you. From
the standpoint of an xml restriction, BaseSeries is just a conglomerate
of BaseEntity and the tags in BaseSeries. I worked around this by
hand-creating an interface and using the interface plugin to apply it to
the restricted element. It would be nice if xjc could generate an
interface that incorporates the common methods between the restricted
entities, but I can see how this could get out of hand when there are
hierarchies further based on a restriction.
Thanks,
Lucas