Joseph Scott was kind enough to respond to my previous post about the poor standards implementation in Wordpress. First off, I want to thank him for taking the time to respond in a comment. It's great that there's transparency and conversation - that's why WordPress rocks.

Now, onto the issue at hand. His response was:

I think you missed the point of my comment. All of the clients that you mentioned work with WordPress categories out of the box. Some of them do this by not using metaWeblog.getCategories and that's fine.

The point was not that WordPress has such a huge market share that it can dictate how everyone else must do things, but that making such a change could break client code that today works correctly with metaWeblog.getCategories on WordPress. And that is something that I generally try to avoid, because it results in lots of unhappy people.

It is unfortunate situation to be in, but I believe keeping the current behavior was the best option.

First off, yes, it's a totally unfortunate situation to be in. And yes, what they did was in the best interest of WP. I am criticizing their implementation not from the perspective of WordPress, but from the rest of the web. From this perspective, what WordPress did was still wrong.

Before I begin, let me state an important premise: unfortunately, many developers code against tools, not standards. A great example of this is when developers code against browsers, and not the W3C spec, since no browser implements against the ACID tests correctly. A client developer will be coding to solve a particular problem ("I want to post on WordPress") and will only vaguely read the spec. If something doesn't work, they'll try to make it work, irregardless of the spec.

I can't speculate on how this happened, but Microsoft implemented the MetaWeblog spec incorrectly, just like WordPress. Now, I can't imagine this because the "spec is vague" - anybody who reads that spec can see that Winer clearly stated that getCategories returns a struct with structs, not an array of structs (regardless of what other methods return). So was it a coincidence that MSFT implemented it incorrectly? Or did WP's poor implementation lead to a de-facto standard? I don't know. I'm guessing it's a coincidence (an astute reader might want to examine the histories of the implementations and the clients to see how this problem got so large).

Now, both Microsoft and Wordpress have both incorrectly implemented the MetaWeblog API. How does this affect everybody else?

The poor implementation first trickles to the client developers. Some of them will falsely assume that the MS and WordPress implementations (being the market giants that they are) are correct, and will assume the getCategories() returns an array, not a struct and will assume all other services will behave the same (this is the crux of the problem). These are the most troublesome developers.

Other client developers, who read the spec (I'm assuming, like Adrian from ecto) will implement workarounds for WordPress. These people are not troublesome, and they contribute to the interop of the web. They will create special cases for WP and handle it. In my experience with clients, this is the exception, not the rule.

Now, let's say a individual developer (like myself) wants to implement the MetaWeblog API for another application. I happily read the spec, and implement it like Winer says I should.

I download a client application (like MS Writer) and test it out. And find out categories do not work. Because of the two specs floating around on the web. What am I to do?

I have two options: I implement the incorrect de-facto spec from MSFT and WordPress because market share matters, or I implement the correct spec, in the hopes that the next big client implements the spec correctly.

See, the problem is the non-action solution taken from that bug helps WordPress, but it does not help everybody else. It is a typical Microsoft move to shift the spec in the name of backwards compatibility, and that is really damaging for the whole web.

Individual developers like me end up with two sets of clients, both who claim to use the MetaWeblog API: those who implemented the spec correctly, and those who did not. And you know what sucks from my end? I can't tell, when a client hits my API, which version of the API I'm supposed to return to them. Do I return an array or a struct? (A technical solution for this is sniffing the user agent, which I may have to do)

Specs and standards are support to fix this type of problem, not contribute to them.

So yes, I can understand why WordPress did what it did, but they also need to understand that what they are doing is breaking the web. While their intent is not to hurt their clients, because they are so big, what they do ripples across the web. Being an open-source project, I would expect a lot better compliant with open standards, rather than doing it their own way.