You are viewing a plain text version of this content. The canonical link for it is here.
Posted to woden-dev@ws.apache.org by "John Kaputin (JIRA)" <ji...@apache.org> on 2006/07/09 07:20:30 UTC
[jira] Created: (WODEN-44) Create ElementSource as an abstraction
to eliminate DOM dependencies from the Woden API
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
Type: New Feature
Components: Parser
Reporter: John Kaputin
Assigned to: John Kaputin
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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
[jira] Updated: (WODEN-44) Create ElementSource as an abstraction
to eliminate DOM dependencies from the Woden API
Posted by "John Kaputin (JIRA)" <ji...@apache.org>.
[ 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/%3cOFA5F0890D.B88AEDAE-ON8025720C.004F784B-8025720C.0077783C@uk.ibm.com%3e
> 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
[jira] Closed: (WODEN-44) Create ElementSource as an abstraction to
eliminate DOM dependencies from the Woden API
Posted by "John Kaputin (JIRA)" <ji...@apache.org>.
[ 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
[jira] Resolved: (WODEN-44) Create ElementSource as an abstraction
to eliminate DOM dependencies from the Woden API
Posted by "John Kaputin (JIRA)" <ji...@apache.org>.
[ 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
[jira] Updated: (WODEN-44) Create ElementSource as an abstraction
to eliminate DOM dependencies from the Woden API
Posted by "Oshani Seneviratne (JIRA)" <ji...@apache.org>.
[ 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org