- I don’t see how the idea of describing headers as part of the contract can work. WSDL (1.1, at least) leaves this out completely, which is bad; SSDL puts the header description in the contract, which is different - but just as bad. One of the benefits of SOAP is that one can emulate a sort of crude aspect orientation by spec’ing out a way to use SOAP headers to implement a technical feature, such as reliability or security, and combine it with arbitrary business contracts. Within the WS-* stack, the model to do this is to use a policy to specify orthogonal attributes that apply to e.g. an endpoint. What’s the analogy here?
- I really like the idea of using Protocols as extensions to a base spec.
- I’m not sure whether SSDL can be used to specify both sides of a communication, and if so, how the respective definitions would be related.
- I am not totally convinced of the benefits one gains by dropping WSDL’s
operationelements — names are just names.
- If SSDL aims to be a WSDL alternative, the spec itself should not reference WSDL — this way, it only adds complexity instead of reducing it (I still have to read and understand WSDL before I can make sense of SSDL).
- I positively hate the InfoSet-speak of W3C specs, and it’s a pity it has found its way to this spec as well :-)
Anyway, for a first release the content, amount of information, quality and layout is great! It’ll be interesting to see whether SSDL, or (more realistically, some of its ideas as least) find their way into the mainstream.
(On a related note, and somewhat unfairly, I would have been totally enthusiastic had SSDL been the Relax NG of contract languages … maybe some other time :-) )