Pounding Nails in the Floor With My Forehead.

<p>Today Meg Hourihan <a href="http://www.megnut.com/technology/007388.asp">writes</a>:</p>
<blockquote>
<p>I usually keep quiet during the myriad technology debates that flood certain web circles, preferring to just do my coding and building of things. So when I do dig into some technology or other &#8211; often way after all the geeks have argued and hashed to death some obscure techie implementation tidbit &#8211; I&#39;m shocked to discover just how messed up it is. This week&#39;s struggle lies with OPML.</p>
</blockquote>
<p>Keeping <q>keep quiet during the myriad technology debates</q> is probably very wise and more productive thing to do, but I&#39;m not smart enough to listen. </p>
<p>She continues&#8230;</p>
<blockquote>
<p>Unfortunately OPML has a DTD that says you can extend OPML anyway you want (which is crazy talk to me, a DTD you can change? What&#39;s the point?), meaning you can add more elements, or more attributes to your elements. So when someone (me) tries to implement something with various OPML outputs, you (again me) realize that one tool outputs an attribute <q>url</q> while another outputs <q>htmlUrl</q> and a third <q>htmlurl</q> &#8211; all to signify the same thing! Sure, some RegEx can clean this up, but weren&#39;t we trying to avoid all that with XML in the first place? Argh! I just want to be able to develop something and have a strong contact defined. Is that too much to ask? No <q>extends XYZ,</q> no <q>I changed this</q> just <q>this is how you express X</q> and that&#39;s it. Maybe if the format you&#39;re using requires you to change it to represent your data, you&#39;re not using the right format in the first place. </p>
</blockquote>
<p>Reading Megnut&#39;s <a href="http://www.megnut.com/technology/007388.asp">post</a> pains me as I&#39;ve experienced exactly what she writes when it comes to OPML. One of my first MovableType plugin attempts was to develop the ability to display OPML blogroll data in an MT layout. Astounded by the lack of a spec or any clear guidance and beguiled by the differing implementations I gave up and never finished it. (I took up the <a href="http://www.timaoutloud.org/files/mt-plugins/#mt-rssfeed">RSS plugin for MT</a> which was and still equally frustrating, but is far more useful and important in concept then OPML or blogrolls.) One Internet standards pundit once refers to it as the <q>ghetto of XML.</q> I have to agree. It&#39;s pretty absurd and insane. It is also unnecessarily difficult to develop software for.</p>
<p>It&#39;s times like these though, that I feel a bit vindicated when an intelligent and normal person like Meg comes to experience, first hand, something that agitates and bedevils me on a regular basis as a career developer and made me quite very outspoken about. Developers exists for users and not the other way around. Absolutely agree. Technical implementation should be transparent and irrevelant to the user. Absolutely agreed again. What is lost in these idealistic view, is the indirect effect a poorly designed and documented <q>specifications</q> has on the user experience. </p>
<p>(There are a great many shared issues between OPML/blogrolls and RSS 0.9x/2.0. Is it any coincidence that the same <a href="http://www.scripting.com">genius</a> is behind both?)</p>
<p>As a developer I only have so much time and energy. If I am forced to write and test extensive amount of <q>bozo code</q> to protect users from such messiness spilling over into their experience that means less time for me to implement new features. There is also good chance new and unaccounted for bozo will come along that could make the software that was once working as it should becoming unreliable or simple break.</p>
<p>Here is a small example of what I mean. The <a href="http://www.timaoutloud.org/files/mt-plugins/#mt-rssfeed">mt-rssfeed plugin</a> I wrote and released last year before RSS 2.0. It worked as advertised until the new and <a href="http://www.timaoutloud.org/archives/000139.html">unneighborly backwards compatibility hostile <code>&lt;guid isPermalink&gt;</code> was introduced</a>. Thanks to <a href="http://diveintomark.org/archives/2003/07/01/leave_rss_alone"><q>unfunkification</q></a> of RSS feeds like <a href="http://diveintomark.org/">Mark Pilgrim&#39;s</a> and <a href="http://www.kottke.org/">Jason Kottke&#39;s</a> my plugin doesn&#39;t know how to find the link to insert into MT layouts. (Click <a href="http://www.intertwingly.net/blog/1460.html">here</a> for more of the funky RSS stupidity.)</p>
<p>I admit that my code could have been better and I need to fix it, but I don&#39;t have time for what is not a quick fix unfortunately. It doesn&#39;t help that such careless and poor design decisions of a specification is behind this breakage.</p>
<p>What&#39;s more ridiculous is that these specifications have been declared frozen and unchangeable. We now have to hobble along or suffer through <a href="http://www.intertwingly.net/wiki/pie/FrontPage">the reinvention of the wheel</a>. </p>
<p>Meg concludes:</p>
<blockquote>
<p>Which makes me realize that I think some of the problems we&#39;ve had in the weblog community around formats like RSS and OPML might stem from the fact that we use them in manners for which they weren&#39;t designed.</p>
</blockquote>
<p>I don&#39;t know if I entirely agree with this assessment. If a specific is designed properly for extensibility &#8211; a simple core and the ability to extend it with namespaced modules &#8211; it can grow and adapt in a sane and reliable manner. These specifications were not and we see where that has gotten us. The problem is only compounded by a specification being frozen to address new common uses and shortcomings in its predecessors. Unlike meat, freezing a specification doesn&#39;t mean it will resist rot and decay.</p>
<p>We need to come up with better ideas and formats that work and can handle change and adaption. That is my rant for another day though.</p>