[ http://issues.apache.org/jira/browse/WODEN-44?page=all ]
John Kaputin resolved WODEN-44.
-------------------------------
Resolution: Fixed
Resolved. See previous comment.
> 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]
