Hi,
From Axis2 point of view i dont see a requirement for the import wsdl
features right now. I wanted to clarify the functionality. So i am not
sure whether i should open an JIRA for this, even as a post M5 task.
Think we should wait till somebody come up with a usecase.

The original idea to use the element model was that i will be doing
lot of policy parsing at the infoset level. May be this isn't a veto
issue. Actually when Jeremy suggested this i actually tried quickly
moving to the component model because i hate to go through the pain of
parsing the imports myself. It lead to lot of hacks last time.
Thanks for the tip for converting the entire model to component model
and converting the particular component to the element. Wasn't aware
of that. This would come in handy for me.
Will query any complications.
Thanks
Chathura

On 5/23/06, John Kaputin <[EMAIL PROTECTED]> wrote:
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]




--
Chathura Herath
http://people.apache.org/~chathura/
http://chathurah.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to