Re: extensions in WSDL CM, in Woden

Hi Jacek,
good point! I guess I was thinking at the document level rather than the
component model when I proposed the qname argument in my example.

What we have now, in the statically defined API, are methods that refer
explicitly to extension properties - like getSoapMepDefault() or
getSoapVersion().  I think we can replace these with a generic style of
getter method that takes the type of extension property as an
argument....but not as a qname argument.  Rather as a 'name' in some other
format, as you suggest.  For the pre-defined extensions these could be
defined as constants on the Woden API, but in anycase the new extension
programming model should probably include a mechanism to register the
'names' of the extension properties so that other extensions can be easily
used with Woden.

Will give this more thought when I get on to WODEN-42.

thanks,
John.

On 5/3/07, Jacek Kopecky <jacek.kopecky@deri.org> wrote:
>
> Hi John,
>
> thanks for the background info, I now understand better how Woden got
> where it is. Since I have my workaround, which does the job with the
> exception of the relatively minor bug WODEN-158, the fix is not urgent
> for me.
>
> Alas, there is one point in what you described that might get hairy:
>
> While WSDL extensions are namespace-qualified, the WSDL component model
> properties resulting from these extensions are not. For instance,
> wsoap:mep results in {soap mep} property. In fact, another extension,
> my:fancyDefaulting="true" for instance, may also create {soap mep}.
> I believe this is the intention of the WSDL spec. How should Woden react
> to this kind of situation?
>
> IMO, getExtensionProperty() should be able to take the name like "soap
> mep" and not just the qname like wsoap:mep. Both options could be
> offered. But just with the qname, it could be hard or counterintuitive
> to implement my:fancyDefaulting as a Woden extension.
>
> Just something that we may want to be cautious about,
> Jacek
>
> On Thu, 2007-05-03 at 17:49 +0100, John Kaputin (gmail) wrote:
> > Jacek,
> > Originally, in Woden M6 (mid-2006), extension properties were grouped
> > strictly by namespace into statically defined types like
> > HTTPBindingExtensions and SOAPBindingExtensions. So the
> > isHttpCookies() method was only present on HTTPBindingExtensions and
> > to retrieve the extension properties of a Binding component where the
> > binding type was SOAP and the protocol was HTTP, two invocations of
> > Binding.getComponentExtensionsForNamespace(uri) were required; one
> > specifying the SOAP namespace to return SOAPBindingExtensions and one
> > for the HTTP namespace to return HTTPBindingExtensions.
> >
> > At the 2nd WSDL2 interop in November a different POV was put forward
> > that it should be possible to get all of the extension properties for
> > a binding 'type' in one go. So for a SOAP binding type the method call
> > Binding.getComponentExtensionsForNamespace(soap NS uri) would return a
> > SOAPBindingExtensions object that exposed the SOAP extensions
> > properties and also, if the protocol was HTTP, the relevant HTTP
> > extension properties. Hence the duplication of some of the HTTP
> > extension properties in the SOAP extension interfaces. This is what we
> > ended up with in Woden M7, although the method should probably have
> > been renamed to getComponentExtensionsForBindingType(uri) which more
> > accurately reflects it's current behaviour.
> >
> > However, that doesn't solve the problem you pose.
> >
> > I think the fundamental problem is that the extensions API evolved
> > from my data model view of the extension properties rather than a
> > proper understanding of their use cases and we've ended up with this
> > grouping of extension properties into statically defined interfaces
> > and methods. A meeting with Glen Daniels at ApacheCon last year about
> > extensions use cases for tools and generic GUIs led me to open JIRA
> > WODEN-42 to change the extensions programming model to make it more
> > generic and flexible. Due to CR completion priorities I didn't have
> > time to implement the solution, but I have now targetted WODEN-42 for
> > our next milestone M8 and I intend to start working on it when I've
> > completed WODEN-122. Your description of your RDF mapping requirements
> > is both useful and timely.
> >
> > With WODEN-42 I expect there will be some new abstraction representing
> > an extension property and methods available on WSDL components to
> > return a collection of extension properties by some criteria. As
> > examples, getExtensionPropertiesForNamespace(uri) and
> > getExtensionPropertiesForBindingType(uri).  I think there will also be
> > methods to retrieve a specified property - for example,
> > getExtensionProperty(qname).  I think I can understand your use case
> > from your previous post and I'll post again when I have some code in
> > Woden trunk for you to try out, but in the meantime tell me if you
> > have any requirements that I may not have covered above.
> >
> > regards,
> > John Kaputin.
>
>
>