Disclaimer: Nothing in these posts should be taken as a criticism of any individuals or organisations involved in the WS-Addressing Spec. It isn’t.
When it comes to developing computing ‘standards’, it’s important that they are well understood.
Why? Because the whole point of them is that different people can develop hardware or software that works in the same way and in many cases work together. If that can’t be achieved then the standard isn’t worth reading.
I’ve now been involved in the WS-Addressing standardisation effort for a full year and though I’ve been a follower of open standards for many years (in particular the W3C when I was involved with mozilla), I didn’t appreciate quite how difficult this task is. This appreciation has come both from the interoperability testing events I’ve been involved in and from the weekly teleconferences I regularly attend.
The difficulties appear, to me, to fall into 3 categories:
- Different parties want different things
- Gaining a common understanding of the specified syntax
- Gaining a common understanding of the specified semantics
All of these difficulties are exhibited in both the specification development and specification testsing phases though #1 is more prevalent in the development phase. That different companies and individuals have different agendas will come as a surprise to no-one, and neither will the fact that is causes some problems.
“A camel is a horse designed by committee.” Committees use compromise as a route to agreement. Entirely reasonable, and in general a good way to work. I don’t believe WS-Addressing looks much like a camel (in fact I think it’s pretty good), though there are a couple of sentences that are metaphorical camels. These sentences were discussed at length, arrivied at as a compromise, pleased all the parties equally, however are very hard to understand were you not in those meetings.
Standards Development Challenge #1: Prevent compromise wordsmithing from hindering understanding
Beyond the standards development phase, and into the product implementation phase, the motivations of a company or developer can shape how the ‘standard’ is read and interpreted, and subsequently implemented. These assumptions or prejudices may never occur or may not show up until well after any formal interoperability testing has occurred as many implementors may not be involved.
Standards Development Challenge #2: Provide implementations developers with the capability to check their assumptions (if not their implementation) in the future
Gotta run, more soon.
