<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Two approaches to standardization</title><link>http://blogs.msdn.com/mikechampion/archive/2005/11/01/487718.aspx</link><description>This is an important topic that I've been meaning to blog about for months, but can't summon the energy to write the dissertation-length post that would do it justice. I think I'll take the typical blogosphere approach of throwing out random thoughts</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: Two approaches to standardization</title><link>http://blogs.msdn.com/mikechampion/archive/2005/11/01/487718.aspx#487788</link><pubDate>Tue, 01 Nov 2005 22:25:43 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:487788</guid><dc:creator>Steve Loughran</dc:creator><description>As someone who does work in standards bodies, I understand a lot what is wrong with them. They are slow, they tend to compromise, and there is a lot of pressure by influential-yet-ignorant people to adopt things (WS-RF) that dont make sense.&lt;br&gt;&lt;br&gt;However, I dont think that the WS-* process is the right one, no matter how much MS and IBM proclaim its value. Case in point. WS-Addressing.&lt;br&gt;&lt;br&gt;Spec status: nearly at 1.0&lt;br&gt;number of tests: 0 as of 1/oct&lt;br&gt;&lt;br&gt;probability of an implementation complying with the spec when there are no formal tests for compliance: 0&lt;br&gt;&lt;br&gt;probably of WS-* interop given that WS-A interop is so low: 0&lt;br&gt;&lt;br&gt;All those interop festivals may help the vendors make sure their implementations are vaguely consistent, but the cost of participating is steep and does nothing to ensure that any of the specs actually meet the original standard.&lt;br&gt;&lt;br&gt;Standards need to go test driven.&lt;br&gt;&lt;br&gt;Also, there is a third way of developing. Open Source. A single codebase is developed in purpose, with tests. No need for committees of architects. No need for multiple codebases. One codebase, whose unit tests provide the formal definition of behaviour. &lt;br&gt;</description></item><item><title>re: Two approaches to standardization</title><link>http://blogs.msdn.com/mikechampion/archive/2005/11/01/487718.aspx#487851</link><pubDate>Tue, 01 Nov 2005 23:53:50 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:487851</guid><dc:creator>Bill Donoghoe</dc:creator><description>Isn't XML 1.0 an example of &amp;quot;quickly and well&amp;quot;.  I have often wondered why this worked.  My thoughts on the factors at play are:&lt;br&gt;a. the ability of the editor of the specification to &amp;quot;get on with it&amp;quot;.&lt;br&gt;b. the fact that the marketing divisions within software companies hadn't discovered &amp;quot;standardisatiion&amp;quot; (cynical I know); and&lt;br&gt;c. The significance of the standard was underestimated by nearly everyone (not important so it was left to those who were only interested in the result and not other agendas). </description></item><item><title>re: Two approaches to standardization</title><link>http://blogs.msdn.com/mikechampion/archive/2005/11/01/487718.aspx#488660</link><pubDate>Thu, 03 Nov 2005 17:13:15 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:488660</guid><dc:creator>mikechampion</dc:creator><description>Rick Jelliffe &lt;a rel="nofollow" target="_new" href="http://www.oreillynet.com/pub/wlg/8313"&gt;http://www.oreillynet.com/pub/wlg/8313&lt;/a&gt; calls this the &amp;quot;donut line method of standardization&amp;quot; (conversations in the donut line at PDC presumably substitute for a rigorous standards review process).  That seems to miss a point that I admittedly did not make clear: Once a spec is given the imprimatur of a standards organization, it is the *organization* that owns the standard, prevents the originator from exploiting an ownership, and generally prevents the kind of stuff that happened in the Bad Old Days.  The process we prefer where specs are pretty well cooked and field-tested *before* being submitted to a standards group is not how things have worked in the Web standards world, but require few if any changes to the standards orgs or their formal processes.</description></item><item><title>re: Two approaches to standardization</title><link>http://blogs.msdn.com/mikechampion/archive/2005/11/01/487718.aspx#488902</link><pubDate>Fri, 04 Nov 2005 05:07:11 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:488902</guid><dc:creator>Rick Jelliffe</dc:creator><description>&amp;quot;That seems to miss a point that I admittedly did not make clear&amp;quot; &lt;br&gt;&lt;br&gt;I would like to address some other points that you also did not make: your unstated recommendation that all kittens should be drowned, in particular: MS is going too far, in my opinion. Not to mention your unstated announcement of Windows Live's policy that everyone must have a first name beginning with &amp;quot;M&amp;quot; and a funny red hat. These are hardly credible, and I never would have raised these issues except for their admitted non-presence!</description></item></channel></rss>