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"
<[EMAIL PROTECTED] To
m> [email protected]
cc
07/07/2006 00:07
Subject
Re: [Vote] ElementSource to wrap
Please respond to element info items
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
