Following on from my earlier post about WS standardisation. Steve Vinoksi points out that traditional standardisation efforts are often too slow and overly political. In this month’s IEEE Distributed Systems Online (DSO) he discusses WS-NonexistentStandards. Lots of standardisation work but where are the accepted standards and how does the process facilitate the creation and adoption of practical standards?
To get around these problems, WS-* authors appear to be taking a different approach toward standardization:
- Write a specification and make it publicly available.
- Invite interested parties to one or more private workshops where they can learn more details about the specification and provide feedback.
- Iterate steps 1 and 2 until chosen feedback from the workshop participants has been incorporated, and the specification is considered finished.
- Submit the specification to an official standards body with the hope of fast tracking it to actual standardization with minimal changes.
Overall, this approach reduces the number of participants involved, which can be a good thing because it reduces the overall volume of communication required to create the specification and resulting standard. However, it can also reduce the resulting standard’s effectiveness, even rendering it useless, because it circumvents at least some of the process of building consensus by not being a truly open process. A standard that is not generally agreed on is a standard on paper only.
This definitely seems to be part of the problem. It’s in marked contrast to the IETF standardisation process which often appears much more open and perhaps democratic. However, it’s a fine line to walk. I can’t help but feel that 2 modifications to the process would significantly improve matters.
- The creation of WS-arch so we can categorically say what piece of the WS-jigsaw goes WS-where? đŸ˜‰
- Incentivised involvement of independent s/w developers in the standardisation process. Spec consumers rather than spec producer/pushers who can’t provide neutral guidance. Maybe even some decisions could be put to general developers using a web-based voting system.
Probably/definitely need to think about this more…