[ http://issues.apache.org/jira/browse/WODEN-44?page=all ]
Oshani Seneviratne updated WODEN-44:
------------------------------------
Attachment: woden-44.patch
******************
woden-44.patch
******************
This patch includes the implementation of the ElementSource and it's related
classes in the WODEN-44 branch.
With this, I have removed all the DOM dependencies in XMLAttr,
ExtensionDeserializer, etc, etc.., In those classes, method signatures are
changed to take in Objects instead of org.w3c.dom.Elements. If a particular
attribute in this DOM/OM element wrapped in ElementSource, is required, the
static methods in the 'ElementUtils' is used.
The class ElementUtils, acts as a switch for DOM/OMUtils. However there is no
inheritance mechanism here. It is used as an alternative to DOMUtils which was
there to get any attribute specific information from the elements. There is a
possiblity to remove these static method references, and have the two util
classes extend from ElementUtils later.
Also QNameUtils is refactored to avoid possible confusion with the same class
name in the two o.a.w.i.util.dom/om packages.
There are other code fixes that are not related to this JIRA. These include the
introduction of OMWSDLSource and several code fixes in the OMWSDLReader.
NOTE: One of the other objectives of this JIRA, i.e representing <xs:schema>
element in a WSDL as an ElementSource is NOT implemented in this patch.
> 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]
