ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Ws Wiki] Update of "FrontPage/Woden/APIReview/XmlSchemaDependency" by JohnKaputin
Date Thu, 15 Nov 2007 15:38:25 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.

The following page has been changed by JohnKaputin:

The comment on the change is:
added API issue, XmlSchema dependency

New page:
= API depends on XmlSchema =

In some places, the Woden API specifies schema object types defined by the Apache WS-Commons
Xml``Schema model. This satisfies the needs of Axis2 and other projects that depend on WS-Commons
Xml``Schema for their schema support. However, it places a burden on other implementors of
the Woden API to either use WS-Commons Xml``Schema 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 Xml``Schema.

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 {{{}}}
and the client should cast the Object returned by {{{ElementDeclaration.getContent()}}} to
{{{}}}. 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 Xml``Schema are:

 * {{{XmlSchemaElement InterfaceFaultElement.getXmlSchemaElement()}}}
 * {{{XmlSchemaElement InterfaceMessageReferenceElement.getXmlSchemaElement()}}}
 * {{{XmlSchemaElement SOAPHeaderBlockElement.getElement()}}}
 * {{{XmlSchemaType HTTPHeaderElement.getType()}}}
 * {{{XmlSchema Schema.getSchemaDefinition()}}}

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.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message