[ http://issues.apache.org/jira/browse/WODEN-44?page=all ]
John Kaputin updated WODEN-44: ------------------------------ This JIRA is now resolved. The solution described at [1] is different to the original proposal above. Rather than just creating ElementSource as a wrapper for a DOM Element or OMElement, a new interface 'XMLElement' has been created instead with the implementations DOMXMLElement and OMXMLElement. This interface defines common behaviour for accessing element content and the implementations largely replace the behaviour defined in DOMUtils and OMUtils which were used extensively in DOMWSDLReader and OMWSDLReader. So, as well as using this new element abstraction in the API method signatures instead of DOM Element or OMElement, the WSDLReader implementation can now be largely based on XMLElement . The parse methods in DOMWSDLReader and OMWSDLReader that were very similar but based on DOMUtils and OMUtils respectively have now mostly been refactored into BaseWSDLReader and are based on XMLElement instead. [1] http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200610.mbox/[EMAIL PROTECTED] > Create ElementSource as an abstraction to eliminate DOM dependencies from the > Woden API > --------------------------------------------------------------------------------------- > > Key: WODEN-44 > URL: http://issues.apache.org/jira/browse/WODEN-44 > Project: Woden > Issue Type: New Feature > Components: Parser > Reporter: John Kaputin > Assigned To: John Kaputin > Attachments: woden-44.patch > > > Original proposal to woden-dev mailing list 6 July 2006: > 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 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
