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 <KA...@uk.ibm.com> on 2006/07/06 16:34:36 UTC
[Vote] ElementSource to wrap element info items
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
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: [Vote] ElementSource to wrap element info items
Posted by John Kaputin <KA...@uk.ibm.com>.
Hi Oshani,
thanks for your comments - I prefer having others think about this too and
appreciate the feedback on my suggestion.
The DOM element passed to the init method is only used for resolving
namespace prefixes for attributes whose type includes xs:qname. If this
was the only use of a DOM element in the Woden API, I'd probably prefer to
do away with the ownerEl arg in the method signature and use some other
approach. However, DOM element is also used in the deserializer so I just
went with the option of replacing all occurrences of it with this
ElementSource abstraction. We could still modify the XMLAttr.init method,
but I've been thinking anyway about a broader review of how wsdl and
extension attributes are handled in Woden so just went with the simple
change for now - i.e. init(ElementSource, QName, String).
ExtensionDeserializer.unmarshall relies more heavily on DOM element arg
than XMLAttr.init. This arg represents the extension element itself and is
used by the unmarshall method to extract the extension element contents.
My initial thinking was that for ElementSource, as with the WSDLSource
abstraction, the client application needs to know which Woden
implementation it is using so it can cast the source Object returned by
ElementSource to an appropriate type ( e.g. to a DOM Element or OMElement)
and then use the appropriate API to access the element's attributes and any
child elements. However, your question about retrieving the elements
attributes from ElementSource is interesting - perhaps we should add
methods to ElementSource that get attributes and children, etc, then let
the ElementSource implementation delegate these requests to the underlying
DOM Element or OMElement or whatever. In this case, there's no need to
retrieve the source Object and cast it.
I'll open a JIRA on this and do the initial work in a subversion branch
where you can review it and comment.
thanks,
John Kaputin
"Oshani
Seneviratne"
<oshanis@gmail.co To
m> woden-dev@ws.apache.org
cc
07/07/2006 00:07
Subject
Re: [Vote] ElementSource to wrap
Please respond to element info items
woden-dev@ws.apac
he.org
Hi John,
Your proposal looks really good, and it would be a good way to support
the 2 parsing models. Just to let you know, I have also been thinking
of a solution for this. But I guess I have thought of it in an
entirely different way!
What I've come to realize was that those XMLAttr implemented classes
use the ownerEl (currently a DOM element) mainly to get the QName of
the attribute value. But in some of the classes, it just returns the
attribute value itself without any reference to the ownerEl. In the
case of the ExtensionDeserializer, the ownerEl is used to get
attribute value specific info through DOMUtils.
So, I was thinking of a way in the lines of changing the method
signatures of those XMLAttr classes and ExtensionDeserializer that use
DOM elements. These signatures could be somewhat generic ones, where
it would be possible to directly send the required info without the
need to send the whole element. I really do not know whether there are
any other requirements in those classes that needs to be satisfied
from the ownerEl. If so, this approach won't be that good and also
there could be other code changes that I have not foreseen.
So, lets go with your proposal which is cleaner and is much more
elegant :). However, I have one particular concern. How would it be
possible to obtain the attribute specific info (which I believe to be
a parser specific thing in the current approach) from an
ElementSource?
For eg: in all of the unmarshall method implementations of the
ExtensionDeserializer, DOMUtils is used to obtain the attribute info.
So, there is a need to have a check to see what kind of an instance we
are getting for the ElementSource and use DOMUtils or OMUtils
accordingly there, isn't it?. I suppose this is not a problem, but I
am wondering whether there is a way to abstract this. I apologise if
I'm missing something very obvious!
Thanks and Regards,
Oshani
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: [Vote] ElementSource to wrap element info items
Posted by Oshani Seneviratne <os...@gmail.com>.
Hi John,
Your proposal looks really good, and it would be a good way to support
the 2 parsing models. Just to let you know, I have also been thinking
of a solution for this. But I guess I have thought of it in an
entirely different way!
What I've come to realize was that those XMLAttr implemented classes
use the ownerEl (currently a DOM element) mainly to get the QName of
the attribute value. But in some of the classes, it just returns the
attribute value itself without any reference to the ownerEl. In the
case of the ExtensionDeserializer, the ownerEl is used to get
attribute value specific info through DOMUtils.
So, I was thinking of a way in the lines of changing the method
signatures of those XMLAttr classes and ExtensionDeserializer that use
DOM elements. These signatures could be somewhat generic ones, where
it would be possible to directly send the required info without the
need to send the whole element. I really do not know whether there are
any other requirements in those classes that needs to be satisfied
from the ownerEl. If so, this approach won't be that good and also
there could be other code changes that I have not foreseen.
So, lets go with your proposal which is cleaner and is much more
elegant :). However, I have one particular concern. How would it be
possible to obtain the attribute specific info (which I believe to be
a parser specific thing in the current approach) from an
ElementSource?
For eg: in all of the unmarshall method implementations of the
ExtensionDeserializer, DOMUtils is used to obtain the attribute info.
So, there is a need to have a check to see what kind of an instance we
are getting for the ElementSource and use DOMUtils or OMUtils
accordingly there, isn't it?. I suppose this is not a problem, but I
am wondering whether there is a way to abstract this. I apologise if
I'm missing something very obvious!
Thanks and Regards,
Oshani
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org