In a post entitled Dare Obasanjo is raining on the W3C's parade, Mike Dierken responds to my recent post which asks Is the W3C Becoming Irrelevant? by writing

Either way the primary mechanism the W3C uses to produce technology specs is to take a bunch of contradictory and conflictiong proposals then have a bunch of career bureaucrats try to find some compromise that is a union of all the submitted specs

Damn those career bureaucrats that built XML. Or is it the SOAP design process that caused the grief? And where did that technology come from anyway?

My original post already described the specs that have caused grief and show the W3C is losing its way. I assume that Mike is trying to use XML 1.0 and SOAP 1.1 as counter examples to the trend I pointed out. Well first of all, XML 1.0 was a proposal to design a subset of SGML so by definition it could not suffer the same problems that face attempts to innovate by committee which have hampered the W3C in current times. Also when XML 1.0 was created it was much smaller and a majority of the participants in the subsetting of SGML had similar goals. As for SOAP 1.1, it isn't a W3C spec. SOAP 1.1 was created by Don Box, Dave Winer and a bunch of Microsoft and IBM folks and then submitted to the W3C as a W3C Note.

Of course, the W3C has created iterations of both specs (XML 1.1 & SOAP 1.2) which in both cases are backwards incompatible with the previous versions. I leave it as an excercise to the reader to decide if having backwards incompatible point releases of Web specifications is how one 'leads the Web to its full potential'.

While reading Dave Winer's blog today I stumbled on a link to the New York Times editorial on the Sentate Intelligence Committee's recent report. Below is an excerpt

In a season when candor and leadership are in short supply, the Senate Intelligence Committee's report on the prewar assessment of Iraqi weapons is a welcome demonstration of both. It is also disturbing, and not just because of what it says about the atrocious state of American intelligence. The report is a condemnation of how this administration has squandered the public trust it may sorely need for a real threat to national security.

The report was heavily censored by the administration and is too narrowly focused on the bungling of just the Central Intelligence Agency. But what comes through is thoroughly damning. Put simply, the Bush administration's intelligence analysts cooked the books to give Congress and the public the impression that Saddam Hussein had chemical and biological weapons and was developing nuclear arms, that he was plotting to give such weapons to terrorists, and that he was an imminent threat.

These assertions formed the basis of Mr. Bush's justifications for war. But the report said that they were wrong and were not a true picture of the intelligence, and that the intelligence itself was not worth much. The freshest information from human sources was more than four years old. The committee said the analysts who had produced that false apocalyptic vision had fallen into a "collective groupthink" in which evidence was hammered into a preconceived pattern. Their bosses did not intervene.

The report reaffirmed a finding by another panel investigating intelligence failures before the 9/11 attacks in saying that there was no "established formal relationship" between Saddam Hussein and Al Qaeda. It also said there was no evidence that Iraq had been complicit in any attack by Osama bin Laden, or that Saddam Hussein had ever tried to use Al Qaeda for an attack. Although the report said the C.I.A.'s conclusions had been "widely disseminated" in the government, Mr. Bush and Vice President Dick Cheney have repeatedly talked of an Iraq-Qaeda link.

Sadly, the investigation stopped without assessing how President Bush had used the incompetent intelligence reports to justify war.

It is now quite clear that GW Bush and his cronies started a war that has claimed the lives of hundreds of Americans and thousands of Iraqis, cost the US and Iraq billions of dollars, and has increased the negative feelings towards the US across the world [especially in the Middle East] for no just cause. What I'd like to know is if anyone is going to go to is what the legal punishment for their transgressions actually will be.

Growing up in Nigeria, I saw first hand what happens when the government commits crimes against the people with no fear of accountability. Lack of accountability seeps into the national fabric and varying degrees of corruption follow. Hopefully, America won't follow the example of the tin pot dictatorships across the third world where everyone knows the governments lie and are corrupt but shrug it off as being a way of life.

Bush and his cronies are destroying America and everything it stands for one day at a time. I pray we don't get four more years of this disaster.

For a long time I used to think the W3C held the future of the World Wide Web in its hands. However I have come to realize that although this may have been true in the past the W3C has become too much of a slow moving bureaucratic machine to attract the kind of innovation that will create the next generation of the World Wide Web. From where I sit there are three major areas of growth for the next generation of the World Wide Web; the next generation of the dynamic Web, syndication and distibuted computing across the Web. With the recent decisions of Mozilla and Opera to form the WHAT working group and Atom's decision to go with the IETF it seems the W3C will not be playing a dominant role in any of these 3 areas.

In recent times the way the W3C produces a spec is to either hold a workshop where different entities can submit proposals and then form a working group based on coming up with a unification of the various proposals or forming a working group to find come up with a unification of various W3C Notes  submitted by member companies. Either way the primary mechanism the W3C uses to produce technology specs is to take a bunch of contradictory and conflictiong proposals then have a bunch of career bureaucrats try to find some compromise that is a union of all the submitted specs. There are two things that fall out of this process. The first is that the process takes a long time, for example the XML Query workshop was in 1998 and six years later the XQuery spec is still a working draft. Also XInclude proposal was originally submitted to the W3C in 1999 but five years later it is just a candidate recommendation. Secondly, the specs that are produced tend to be too complex yet minimally functionaly since they compromise between too many wildly differing proposals. For example, W3C XML Schema was screated by unifying the ideas behind DCD, DDML, SOX, and XDR. This has lead to a dysfunctional specification that is too complex for the simple scenarios and nigh impossible to use in defining complex XML vocabularies.

It seems many vendors amd individuals are realizing that the way to produce an innovative technology is for the vendors that will mostly be affected by the technology to come up with a specification that is satisfactory to the participants as opposed to trying to innovate by committee.  This is exactly what is happening with the next generation of the dynamic Web with the WHAT working group, with XML Web Services with WS-I and in syndication with RSS & Atom.

The W3C still has a good brand name since many associate it with the success of the Web but it seems that it has become damage that vendors route around in their bid to create the next generation of the World Wide Web.

I often think to myself that there is a lot of background racism in the United States. By background racism, I mean racism that is so steeped into the culture that it isn't even noticed unless pointed out by outsiders. One example sprang to mind after reading Robert Scoble's post Did China beat Christopher Columbus by decades? where he writes

Speaking of Chinese, I'm reading a book "1421 The Year China Discovered America" that makes a darn good case that Christopher Columbus didn't discover America. He's done a ton of work that shows that the Chinese were actually here 60 years prior and that Christopher Columbus actually had copies of their maps!

That basically throws out a whole ton of history I learned in elementary school.

What I find interesting is this concept of "discovering America". There were already people on the North American content when Columbus [or the Chinese] showed up in the 15^th century. So "discovered" really means "first European people to realize the American continent existed". Now every child in America is brought up to believe that Europeans showing up on some land that was already inhabited by natives is "discovering America" and introducing it to the world. 

This makes me wonder how much the history lessons I received growing up in Nigeria differs from the version British kids got about the African colonies. Perhaps there is also some white guy celebrated for having "discovered Africa" and civilizing the black savages who he met when he got there. At least whatever tribes that welcomed whoever he was aren't extinct today, too bad you can't say the same for the tribes that greeted Columbus.    

Whenever I'm up late and can't sleep I like checking out the HipHopMusic.com. I like reading the discussions, where else can I find a discussion of a lawsuit being filed against Snoop Doggy Dogg for using a voice mail message on his album detoriorate into gang bangers threatening to cap each other over the Web or watch a review of Jay-Z's most recent album turn into a six month long discussion about whether Jay-Z is the greatest of all time (G.O.A.T.) or not.

Speaking of hip hop the new album by 213 (Snoop, Nate Dogg and Warren G), The Hard Way, is scheduled to drop within the next month. I've been waiting over 10 years for this album. There is a God in heaven listening to our prayers. :)

To help both our users and the RSS Bandit development team I have produced an RSS Bandit Product Roadmap. From the introduction to the roadmap

As the user base and development team of RSS Bandit has grown the need for planning and strategy documentation for future versions of RSS Bandit has become self evident. This document describes the goals for future versions of RSS Bandit as well as provide a plan for achieving these goals. As RSS Bandit is an Open Source project worked on by members of the RSS Bandit community in their free time these plans and goals will not be fixed which is why this document is a living document available on the wiki. There are three primary goals of this road map

• it is a way to communicate to our end users what features are planned for the next release

• it communicates the prioritization of various features as well as defines owners for feature areas

• it defines the requirements of each feature in enough detail that the RSS Bandit development team can implement these features

At the current time this road map describes the future of the current version of RSS Bandit (v1.2.0.114) and the following version. Since we do not know the what version number an RSS Bandit release will use until it is released we will use code names for future releases. The release following v1.2.0.114 is codenamed Wolverine after the character from the X-Men comic book.

This document is primarily for the benefit of Torsten, Phil and myself although I am sure our users will find it of interest as well. If you have any feedback on the roadmap, let me know by posting a comment.

In The Problem With Online Music Tim Bray writes

The New York Times today hits the nail on the head: if you’re buying music over the net, you’re buying it in severely damaged condition. When I plug my computer into the really good stereo at home, the difference between the way music sounds coming off CD or vinyl or a good FM signal, and the crippled version from MP3 compression isn’t subtle. I used to think that if you were listening to music on headphones on a bus or train or plane or in a crowd, the MP3 lossage really didn’t matter much.

Then there are people like me who have a Bose sound system in their car but find out much to our chagrin that MP3s playing off of an iPod sound better than CDs since the iPod has EQs and the car stereo does not.

In chapter 26, of The Dilbert Principle Scott Adams proposes guidelines for good management which should promote a healthy workplace. On pages 317 & 318 he writes

Rule for "one off" activities: consistency. Resist the urge to tinker. It's always tempting to "improve" the prganizational structure, or to rewrite the company policy to address a new situation, or to create committee to improve employee morale. Individually, all those things seem to make sense. But experience shows that you generally end up with something that is no more effective than what you started with.
...
The best example of a fruitless, "one off" activity that seems like a good idea is the reorganization. Have you ever seen an internal company reorganization that dramatically improved either the effectiveness of the employees or quality of the product?

I found this excerpt particularly relevant because at my day job [at Microsoft] reorganizations are a way of life. Based on conversations with coworkers and my experiences being in Redmond just over 2 years, the average product team goes through one reorganization a year. The average B0rg drone has the line between them and the CEO in the org chart altered at least once a year. At least one news publication has described it as Microsoft's Annual Spring Reorg. When I first got to Microsoft I'd heard people joke about this but having gone through 2 changes in management and 2 team reorgs in as many years the jokes don't seem as far fetched any more. 

About a year ago [or longer] there was a 'meet-the-CEO' style meeting where Steve Ballmer gave a talk followed by a Q & A session with employees in one of teh conference rooms. I didn't attend because I knew the room would be filled to capacity but did watch the live Webcast. One of the things he talked about was the negative effect of frequent reorgs. Paraphrasing, I believe he said with reorgs we take teams of people who've learned how to work together and function as a team and disrupt them by asking them to start the team building process all over again with new counterparts. Recently I noticed another detriment to regular reorganizations which involve changes of management.

Our team recently had a project post mortem where we discussed what things had gone right or wrong on the journey towards getting to beta 1 of v2.0 of the .NET Framework. One of the things that came up were issues with some management decisions that were made at the start of the project which were reinforced during the middle of the project by new management. What I found interesting was that the main management folks who had made these decisions weren't part of the post mortem because they'd been reorged away. Our team has had 3 general managers in the 2.5 years I've been working here and we've been working on Whidbey for almost the entire time. What struck me is that it means that these folks who are now off in other parts of the B0rg cube haven't had to see the pros and cons of the various decisions they made unfold over time or what the ramifications of various trade offs and risky bets they made have been. The entire point of gaining experience is to learn from it. Frequent reorganizations prevent this learning process from occuring. 

Thanks, Dilbert.  

At Microsoft one of our goals in developing software is that backwards compatibility when moving from one version of software to the next is high priority. However in certain cases the old behavior may be undesirable enough that we break compatibility. An example of such undesirable behavior are bugs that lead to incorrect results or security issues. Below is a list of breaking changes in the System.Xml namespace in beta 1 of v2.0 of the .NET Framework.

1. Extension of xs:anyType which changes the content type to mixed="false" results in error.
2. Add an enumeration member to XmlWriter.WriteState to indicate that the writer is in error state. Change writer to disallow further writes when in error state.
3. ##other namespace constraint now treated correctly on wild cards.
4. Instances of DateTime object returned by XmlValidatingReader that represent xs:time and other date & time related W3C XML Schema types now initialized using DateTime.MinValue
5. Incorrect implementation of XSD derivation hierarchy for xs:ENTITY and xs:NCName corrected.
6. XSD List Types Not Validated Correctly.
7. Changed to reliably fail when XmlTextReader source stream switches encoding between calls to ResetState()
8. XmlTextReader should apply the same security restrictions as the XmlReaders that can be created via the static XmlReader.Create() methods

I was directly involved in the decision making process for most of these breaking changes since many are in the W3C XML Schema area which I am responsible for. If any further clarifications about any of the breaking changes is needed, please post a comment with your question below.

I just noticed that the most recent version of RSS Bandit has had over 20,000 downloads in just over a month. It seems like every day I find a new blog post from someone who's switched to RSS Bandit or just started using it as their first aggregator describing their improved user experience compared to other aggregators. Thanks for the support, there is even better stuff on the way.

I've been busy with work so in the meantime Torsten and Phil have been working on bug fixes for some of our most pressing user requests. In between releases we try to produce stable builds which early adopters can test to see if certain persistent bugs have been fixed. These RSS Bandit daily builds do not have an installer but can be downloaded and run directly by double-clicking on the RssBandit.exe icon after unzipping the folder. For example, the 6/15/2004 build fixes an issue with downloading feeds from behind a firewall. It should be noted that these interim builds are not expected to be release quality and have not been tested as rigorously as a full release that ships with an installer. However if you are interested in keeping pace with RSS Bandit development and providing feedback in making it an even better aggregator then keeping up with our daily builds is one way to do that. 

My workload at my day job has eased, so in the next few weeks I have time to work with Torsten on fixing a number of our reported bugs as well as prioritizing and implementing various feature requests. One thing I have noticed is that a number of people would like to get insight into our plans for the next release. The first cut at this was my prioritized Top 10 list of features for the next version of RSS Bandit. However that list doesn't take into account a number of smaller feature items we'd like to do nor does it give much detail about what we will do. Both Torsten and Phil would like to see proper specifications for the next release (requirements document, design docs, etc) which I'd gladly write since writing specs is something I was doing for fun before it became my day job. However this is work that would take away from coding time and since there'd only be one or two other readers of the document(s) I'm unsure as to whether just adding more detail to our existing communication practices isn't a better bet for the long run.

Whatever is decided, we will be blogging about features as they are being implemented and providing builds which showcase the new features so we can get feedback from users.  The only question is how detailed we will be about discussing features before they actually show up as downloadable bits.