Recently, Rich Salz has published an article at xml.com wherein he criticizes WSDL 2 heavily. I used to be active in the WS-Description working group (nowadays I'm mostly lurking there with little time to contribute meaningfully) so here's my opinion on the criticisms.
First a conclusion: while Rich has some good points (and I haven't read his comments formally submitted to the WG), his big complaints (listed below) are at least debatable. That doesn't mean the WSDL specs can't be blamed, maybe they can include some rationales and other explaining texts that would give the readers more understanding. I'm sure Rich's comments will lead to improvement of WSDL 2.
In the first section, "WSDL 2: Just Say No", Rich wants TimBL to come to our face-to-face and spank us all, plus return the documents to us. Rich doesn't have the W3C process right: in Last Call, the documents are publicly reviewed, the comments are handled by the WG, the documents are updated appropriately and only then can they be submitted for the next step, Candidate Recommendation, to start formally gathering implementation experience. Rich has submitted his comments to the WG and the WG is adding them to their issues list. Any such comments that are not resolved to the commenter's satisfaction will later be brought to TimBL's attention so there should be no worry.
In the second section, "No Standard WSDL File", Rich says the spec doesn't contain a valid example WSDL file. The WG decided that the spec itself will not contain such examples, but that a primer will be produced where examples will be abundant. For the developer of a WSDL tool, the spec itself is the guide, as examples may be misleading in their simplicity as to what the actual rules are. The users, on the other hand, need not read the spec, just the primer should suffice. And Rich says there is no normative XML Schema for WSDL - he must have missed table 1-1 which links to it: http://www.w3.org/2004/08/wsdl. The schema also contains a good definition for the "element" attribute that Rich explicitly points out.
The third section, "Yet Another Data Model", complains about the component model of WSDL. This approach to modeling WSDL was chosen because it's (according at least to my limited experience) the easiest way to have a formal model of a language without depending overly on the syntax. Even XML is this way, the infoset is the formal model (even though it came later than the XML 1.0 spec) and XML 1.0 specifies how that is serialized. Infoset doesn't care about single or double quotes around attributes, WSDL component model doesn't care about ordering of XML elements, or even about imports, for that matter.
In the fourth section, "COM Comes Back", Rich mentions that two of the editors raised a formal Last Call objection against the spec. What he misses is that this objection has been here from the beginning, that this issue came down to a vote (after lengthy consensus-seeking) and they were voted down. I'd say "that's life", and the objection will still be considered before the specs become Recommendations. Also, the only mention of COM (implying bad, obsolete technology) is comparing interface inheritance with vtable extension, with no rationale why this would be considered bad.
As for comparing components, I expect a proper tool will seldom really have to compare their properties because the situation will not be common. Let me illustrate on the diamond inheritance scenario: interfaces B and C extend interface A, interface D extends interfaces B and C. A parser will logically get all components from interface A twice, but it can easily remember their source and assume that parsing a single interface twice will, in fact, yield equivalent components.
As for the uniqueness good practice for names inside a component, I expect Rich means the recommendation that multiple interfaces in a single namespace don't define different operations with the same names, which would make it impossible for one other interface to extend both such conflicting interfaces. Yes, if two interfaces would naturally have different operations with the same name, the developer can choose to give them different namespaces, because I strongly believe that namespace URIs are cheap.
Posted at 1020 on Wed, Nov 24, 2004 in category Work | TrackBack