- From: Craig Salter <csalter@ca.ibm.com>
- Date: Tue, 05 Oct 2004 02:04:08 +0000
- To: public-ws-desc-comments@w3.org
- Message-ID: <OF06A31EE9.9CC560DD-ON85256F23.0060BD37-85256F24.000B45C9@ca.ibm.com>
Here's my thoughts on the working drafts. In general its an improvement over WSDL 1.1 but I still feel a need for simplification. Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language 2.4.1.1 Operation Style I think having the interface writer specify the applicable style on an interface or operation is a bad approach. Is the interface writer aware of the possible styles that exist? In addition the style is optional, so tools will still need to function in the absence of the style attribute. Furthermore, specifying the style of the interface blurs the line between interface and binding. I think a better approach would involve supporting extensible interface/message structure constraints via the binding. Using this approach, when the wsdl processor encountered a binding that referenced an interface it would utilize the constraints associated with the specific binding to validate interface. 2.3 Interface Fault Why are fault messages considered 'reusable' but input / output messages are not? This seems inconsistent. A major improvement over WSDL 1.1 is the removal of the top level 'message' components. From my experience there's little benefit to specifying 'named' messages. If these do exist why are they specified within an interface? IMHO the complexities introduced by named messages outweigh any convenience of reuse. 2.5.2 XML Representation of Message Reference Component I don't see any use in the inclusion of a 'messageLabel' attribute. Are there any examples where this is not redundant (deducible from the context)? I think the inclusion of optional attributes/elements in the spec that have no clear usefulness is terribly detrimental and one of the regrettable weaknesses of wsdl 1.1 2.9.2 XML Representation of Binding Component Seems odd that the binding lacks infault and outfault. I'd assume that the structures should be symmetric? These sort of mysterious differences make the spec feel clumsy. 2.9 Binding I'm struck the variety of places where we expect the wsdl author to specify binding related information. An interface has a 'style' (though optional). The binding has a 'type' then there are 'extensibility attributes' used to specify a soap protocol. Then there are 'extensibility elements' and of course this does not include possible use of 'features' and 'properties'. IMHO there are too many mechanisms at play here. I'd suggest returning to the simplicity of the wsdl 1.1 and its use of the extensibility element. Here's a summary of the constructs I feel should be removed and how ... The binding's type attribute. This could be deduced by the namespace of the child extensibility element (e.g. wsdl 1.1). The binding's style attribute. Unneeded .... see comments above on 2.4.1.1. The binding's extensibility attributes. Don't encourage their use. Why not just utilize the attributes of the extensibility elements (e.g. wsdl 1.1). Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings I don't see any description or examples of how to specify the content of a SOAP header? Is the editor's copy incomplete ... I must confess I couldn't make much sense of it. I think having examples included in the Primer would go a long way to making the design clearer. thanks Craig Craig Salter Rational Studio XML Web Services Internet: csalter@ca.ibm.com Notes: Craig Salter/Toronto/IBM@IBMCA
Received on Friday, 8 October 2004 09:11:16 UTC