I'd like to propose creating a new 'wrapper' interface on the Woden API similar in function to WSDLSource. WSDLSource wraps an implementation specific object that represents the WSDL source being passed in to the WSDLReader on a readWSDL(WSDLSource) method (e.g. for the DOM implementation there is a DOMWSDLSource class that takes a DOM Element or Document or a SAX InputSource).
I propose an interface org.apache.woden.ElementSource to represent an implementation specific element information item object, such as a DOM Element for the DOM implementation or an OMElement for the StAX/OM implementation. It will have the methods: public Object getElementSource() - this method will return an Object which the client must cast to the appropriate type. public void setElementSource(Object) - the method implementation must check Object is an appropriate type and throw an exception if not. An example implementation will be org.apache.woden.internal.DOMElementSource which wraps an org.w3c.dom.Element. This can be used to replace org.w3c.dom.Element in method signatures on XMLAttr, ExtensionDeserializer and ExtensionSerializer. This will meet the requirement from Oshani for her StAX/OM implementation to remove DOM dependencies. She could create an implementation OMElementSource to wrap an OMElement. In this way we keep the Woden API 'clean' of any particular XML parsing API or object model. We can also use ElementSource to represent a <xs:schema> element from any underlying object model so that applications may use XML schema parsing APIs other than ws-commons XmlSchema to manipulate schema data if they choose. Their choice of schema parser would need to support the object type(s) wrapped by ElementSource. Woden will still use XmlSchema and expose this via it's API as it currently does. We would need to add a method to org.apache.woden.schema.Schema to return an ElementSource for the <xs:schema> element: public ElementSource getSchemaElement(). This may satisfy a couple of recent requirements against Woden for alternatives to XmlSchema (most recently from Pierre Chatel, although his particular requirement could perhaps be solved by additions to ws-commons XmlSchema). A bigger solution might be pluggable type system support, but probably not any time soon due to other priorities and resources. Please discuss via this mailing list if you have any comments or concerns. I'll open a JIRA if/when this proposal is agreed. regards, John Kaputin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
