[ http://issues.apache.org/jira/browse/WODEN-44?page=all ]
John Kaputin closed WODEN-44. ----------------------------- > 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]
