Chathura,
I don't think it makes sense to flatten the Element model since each document is a separate XML infoset. Maybe you could flatten the <include>s since they are at least in the same namespace, but you'd have to eliminate any duplicate definitions to get a valid WSDL 2.0 infoset, e.g. <interface>s have unique QNames.
I hope you can work with the Component Model.
BTW, you mentioned Policy. Are you processing policy elements in a WSDL 2.0 document? Did you define an extension?
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: [EMAIL PROTECTED]
| John Kaputin <[EMAIL PROTECTED]>
05/23/2006 07:16 PM
|
|
Chathura,
the importDocuments feature of wsdl4j is not in Woden yet. Woden currently
retrieves imported and included documents by default. If there's a
requirement for it it can be added (post M5 preferrably) - we just haven't
considered it yet, that's all. Please raise a JIRA with your requirement.
The Component model does the flattening of Interfaces, Bindings and
Services. For example, the Description.getInterfaces() method collapses the
imports/includes and returns all of the Interfaces in the composite wsdl.
If you have a DescriptionElement returned by the reader, you can call
DescriptionElement.toComponent() to obtain the Description component then
use this to get the flattened view of the wsdl. Will this meet your needs
or do you have a particular need for flattening in the Element model?
Arthur may have something to add on this, but there may semantic issues to
do with flattening the Element model. The WSDL 2.0 spec defines sematic
rules about the scope and visibility of imports in the importing document
that affect the flattened view of the WSDL in the Component model. The
Element model represents the underlying XML, so just collapsing all the
imports in the tree may get you all the InterfaceElements, etc, but this
might not represent valid WSDL 2.0. If we apply the semantic rules from the
Component model to this flattening process, then we effectively have the
Component model anyway. If you particularly need something in the Element
API you don't have in the Component API, perhaps you could use the
Component model API to get the component you need then call its toElement()
method to see its Element interface
e.g. Description.getInterfaces() or getInterface(QName) will return the
flattened set of Interface components that are available to the Description
according to the WSDL 2.0 semantic rules, then Interface.toElement() will
convert the object's interface to InterfaceElement.
Will any of these ideas work?
John Kaputin
"Chathura Herath"
<[EMAIL PROTECTED]
com> To
[email protected]
23/05/2006 05:01 cc
Subject
Please respond to Woden Feature support
[EMAIL PROTECTED]
he.org
Hi devs,
I tried using the wsdlReader.SetFeature(String feature) method and
came to know that only one feature is supported currently.
I am particularly interested in the "javax.wsdl.importDocuments"
feature that was supported in wsdl4j. Is this feature supported
default?? I saw the parseImports in DOMWSDLReader which reads in the
imports from the locations. Wanted to clarify!!
Further is there a way by which i could collapse all the imports to
one Description element so that i need not manually parse the
description elements inside the imports, recursively. I am sure we are
doing this collapsing in the WSDL component model, but i am referring
to the Element model.
Some feedback
This is particularly a woden-user question and may be its time for us
to start a woden user list, or is it already in place. I couldn't find
it in the site.
Just noted that there is a duplication of the VALIDATION _FEATURE_ID
in ReaderFeatures class and WSDLReader interface. Think all the
feature ids should end up in the WSDLReader if there was no specific
reason.
Look forward to provide more feedback as axis2-woden integration
progresses.
Thanks
--
Chathura Herath
http://people.apache.org/~chathura/
http://chathurah.blogspot.com/
---------------------------------------------------------------------
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]
