- From: Glen Daniels <gdaniels@sonicsoftware.com>
- Date: Wed, 15 Sep 2004 16:08:57 -0400
- To: "Tim Ewald" <tewald@microsoft.com>, <www-ws-desc@w3.org>
Hi Tim! We discussed this at the WSDL face-to-face, and resolved the following: First, the particular implementation choice you make for the way you do Operation Name Mapping will generally be specified in a binding or even a <service>, and not so much at the abstract interface level. When this is the case, you wouldn't need to worry about clashes in the way you inquire about below, since there generally would be only one way to meet the requirement for a particular service's component model. Since nothing actively prevents you from in fact declaring Operation Name Mapping (ONM) mechanisms at the interface level, however, your questions are still very valid and interesting to consider. > Can a derived interface meet the Operation Name Mapping > Requirement using a mechanism different from the mechanism(s) > used by its base interface(s)? We ended up resolving this by deciding to move the Operation Name Requirement to the service component, rather than the interface. The rule will now be that either all the GEDs in the interface operations *of a given service* must be unique, or some extension or feature *in scope for that service* must define how the name disambiguation is being accomplished. Since there is already a scoping rule for features, it's easy to determine which ones are active. With custom extensibility elements, it's up to the author of the extension to decide how to determine what the scoping is (i.e. "if you see this extension in the <interface>, it holds for any service with the enclosing interface in its inheritance hierarchy", etc). A larger point - the questions you raise apply not only to ONM, but also to extensions in general. Since we don't constrain the meaning of extensions, it's up to the authors of individual WSDLs to ensure that the set of active extensions/features for a given scope compose well together. Just as it's possible to declare two different extensions which disambiguate operations in incompatible ways, it's possible to declare two security profiles which each require a different (and incompatible) type of encryption. We are adding some clarification text which discusses this. > If not, is it a requirement that a derived interface only > extend base interfaces that use the same mechanism to meet > the Operation Name Mapping Requirement? As mentioned, the requirement is now that for each service, either the GEDs are unique or some in-scope extension declares the disambiguating technique. Therefore it's fine for interfaces to extend anything they want, as long as a compatible set of semantics results when the most-derived interface is used in a service. > If so, is it then the case that a single derived interface > can not extend multiple base interfaces that use different > mechanisms to meet the Operation Name Mapping Requirement? Same answer as above. We will be updating the spec to reflect the changes I mentioned, and we hope this satisfactorily answers your questions. --Glen on behalf of the WSDL WG
Received on Wednesday, 15 September 2004 20:09:10 UTC