Hi Colin,
> Apologies is this is too off topic for the list...
I think you're quite allrigt on topic.
> So, part of my application's data model contains a simple parent-child
> relationship, where you can think of the parent as an event (in the everyday
> sense, not as in onclick) and the child as an attachment containing binary
> data for that event, maybe a pdf or a Word document.
> Anyway, my XSD defines CRUD requests and responses which are consumed by a
> pre-existing web service.
> Here's a snippet of XSD:
> <xs:element name="CreateEventRequest">
> <xs:complexType>
> <xs:all>
> <xs:element name="event" type="app:newEvent"/>
> <xs:element name="eventAttachment" type="app:newEventAttachment"
> minOccurs="0"/>
> </xs:all>
> </xs:complexType>
> </xs:element>
> ...
> ...
> <xs:element name="ReadEventResponse">
> <xs:complexType>
> <xs:all>
> <xs:element name="status" type="app:statusCode"/>
> <xs:element name="event" type="app:existingEvent" minOccurs="0"/>
> <xs:element name="eventAttachment"
> type="app:existingEventAttachment" minOccurs="0"/>
> </xs:all>
> </xs:complexType>
> </xs:element>
> What would be ideal is if I could have both of these implement base
> appRequest and appResponse interfaces, which themselves could also be
> defined in the XSD. I do use <extension> in a few places right now, for
> instance newEventAttachment and
> existingEventAttachment extend baseEventAttachment. But that mechanism
> doesn't feel like the best solution here, which is why I am exploring the
> Inheritance plugin of JAXB2 Basics.
> I don't really know what the best way to define interfaces "on the fly"
> would be, if it isn't possible right now. Probably a new <annotation>.
> Defines maybe? Something like:
> <xs:complexType name="BaseAppResponseInterface">
> <xs:annotation>
> <xs:appinfo>
>
> <inheritance:defines>my.app.package.BaseAppInterface</inheritance:defines>
> </xs:appinfo>
> </xs:annotation>
> <xs:all>
> <xs:element name="status" type="app:statusCode"/>
> </xs:all
> </xs:complexType>
> Here, running a schema with this through XJC would produce a Java interface
> called BaseAppResponseInterface which other classes could implement. The
> interface would consist of a getter and setter for status using a statusCode
> type (defined elsewhere in the XSD.)
> Maybe there's a better way to implement the feature, or maybe there's
> another way of doing already.
"Extracting" interfaces from schema-derived classes makes sense for
me. The inheritance plugin does not cover this - and I think it will
not. There should be another plugin to "extract" interfaces. However,
this task is far from trivial.
My use case for this plugin would be to make something which works
cross-schema. For instance, if we have WMS 1.1.0 and WMS 1.3.0
switching from one version to another is painful at the moment. I'd
like to have someting like WMS 1.x interfaces which both WMS 1.1.0 and
WMS 1.3.0 classes would implement. I can the develop against WMS 1.x
and have no trouble using one WMS version or another - I just switch
the implementation.
However I don't think my use case is your use case. You seem to have
just few interfaces to be implemented - why don't you just write them
manually and use the inheritance plugin? Why doesn't this work?
Bye,
/lexi