API depends on XmlSchema
In some places, the Woden API specifies schema object types defined by the Apache WS-Commons XmlSchema model. This satisfies the needs of Axis2 and other projects that depend on WS-Commons XmlSchema for their schema support. However, it places a burden on other implementors of the Woden API to either use WS-Commons XmlSchema for their schema parsing or, if they want to use a different schema model, to wrapper their schema objects to satisfy the Woden interfaces. For example, an Eclipse project implementing the Woden API might prefer to use Eclipse XSD instead of XmlSchema.
This problem only exists in the Woden Element API. The Woden Component API is already schema object model agnostic, where the getContent() methods of ElementDeclaration and TypeDefinition return java.lang.Object. The getContentModel() method identifies the object model being used for schemas. The Woden client application is most likely coded to use a particular Woden implementation, so the developer should know what to cast the Object to, but getContentModel() can be used if required (e.g. to check the object model or to report a cast exception).
For example, the Woden DOM implementation defines the content model as org.apache.ws.commons.schema and the client should cast the Object returned by ElementDeclaration.getContent() to org.apache.ws.commons.schema.XmlSchemaElement. If the content model was org.w3c.dom, then that cast would be to org.w3c.dom.Element.
The methods in the Woden Element API that are dependent on XmlSchema are:
One solution might be to follow the approach used for ElementDeclaration and TypeDefinition in the Component model. That is, to return java.lang.Object and have a schema model identifier that indicates to the client what to cast the Object to.