Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by JohnKaputin: http://wiki.apache.org/ws/FrontPage/Woden/APIReview/OneWsdlApi The comment on the change is: Edits to API Review issues ------------------------------------------------------------------------------ We need to consider this issue now that the spec is published, but while the Woden API is not yet finalized. The API will be not be deemed 'stable' until the Woden 1.0 release. There is no point in continuing with 2 separate WSDL APIs unless we have users that want them separate or there are fundamental problems that prevent us combining them. - Some potential problems to consider are: + '''Some potential problems to consider are:''' - * The difference between Description component and <wsdl:description> element. + __The difference between Description component and <wsdl:description> element.__ + This difference is reflected in the Woden API between {{{Description}}} and {{{DescriptionElement}}}. In the component model, there is a single {{{Description}}} component as the top-level container for the other WSDL components that make up a service description. There is no notion of composition via import or include, so there are no nested {{{Description}}} components â just a âflattenedâ view of the WSDL contained within a single {{{Description}}} component. By comparison, the WSDL XML infoset supports document composition via {{{<wsdl:import>}}} and {{{<wsdl:include>}}} elements, so a complete service description may contain multiple {{{<wsdl:description>}}} elements (e.g. the service WSDL imports the binding WSDL which imports the interface WSDL). In the Woden Element API this means multiple {{{DescriptionElement}}} linked from a root {{{DescriptionElement}}} via {{{ImportElement}}} or {{{IncludeElement}}}. So, {{{Description}}} and {{{DescriptionElement}}} are not the same thing. {{{Description}}} contains all of the interfaces, bindings and services declared within a top-level or root {{{<wsdl:description>}}} AND within any imported or included descriptions. {{{DescriptionElement}}} represents a single {{{<wsdl:description>}}} element and its directly declared child elements. If the child elements include {{{<wsdl:import>}}} or {{{<wsdl:include>}}}, the corresponding {{{ImportElement}}} or {{{IncludeElement}}} APIs can be used to navigate to any nested {{{DescriptionElement}}}s. - It would be easy enough to combine say Binding and BindingElement into a single interface because they represent the same entity (a single binding) and contain fundamentally the same content (the same binding faults and operations). Combining Description and DescriptionElement requires more thought. Perhaps we could define different sets of methods for âget_local_onlyâ and âget_local_and_nestedâ, with the behaviour of the latter being similar to flattened properties in the Description component. + It would be easy enough to combine say {{{Binding}}} and {{{BindingElement}}} into a single interface because they represent the same entity (a single binding) and contain fundamentally the same content (the same binding faults and operations). Combining {{{Description}}} and {{{DescriptionElement}}} requires more thought. Perhaps we could define different sets of methods for ''get_local_only'' and ''get_local_and_nested'', with the behaviour of the latter being similar to flattened properties in the existing {{{Description}}} component. - Some WSDL infoset not represented in the Component model. + __Some of the WSDL infoset not represented in the Component model.__ + The WSDL elements <documentation>, <import>, <include> and <types> do not have corresponding WSDL components defined â they are infoset only. Likewise, some WSDL attributes are not represented directly as Component properties. For example, descriptionâs targetNamespace is not a Description component property and the messageLabel attribute of binding fault reference is not a BindingFaultReference property (it is only used to determine the corresponding interface fault reference). If we combine the two APIs, the WSDL component model will be mixed with infoset-specific content. This only really matters if Woden users care, but it might well complicate usability for the existing Component API users. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
