lesscode.org


Complexity, Bureaucracy, Fairness  

By Robert Sayre under First they ignore you.., Then they laugh at you..., Then they fight you... on 30. July 2005

The starting line for the first Oklahoma Land Rush, April 22, 1889. (Library of Congress)

Tantek Çelik: “The namespace problem? The short answer is that it’s nothing more than academic chicken-littling. The internet has worked just fine (at many levels, with many applications, specifications) without namespaces. Namespaces try to solve a 1% problem while burdening the 99%, which is always bad economics.”

I disagree. Namespaces can sometimes be a technical hassle, but I’ve noticed that people who rail against them are usually squatting on a set of short strings. Would it be OK for Microsoft to define the meaning of the word “friend?”

Dan Connolly: “There is a time and a place for just using short strings, but since short strings are scarce resources shared by the global community, fair and open processes should be used to manage them.”

If RSS didn’t restrict extensions to namespaced elements, we would have a very ugly scene on our hands by this time. At what point does technical convenience trump social concerns? In this case, RSS favors a little technical complexity in return for less bureacracy and more fairness. Maybe morecode is occasionally worth it.

7 Responses to “Complexity, Bureaucracy, Fairness”

  1. Labnotes » Are microformats going against the grain:

    […] Robert Sayre responds to Tantek Çelik: I disagree. Namespaces can sometimes be a technical hassle, but I’ve noticed that people who rail against them are usually squatting on a set of short strings. Would it be OK for Microsoft to define the meaning of the word “friend?” […]

    pingback at 30. July 2005

  2. Mark Baker:

    “Would it be OK for Microsoft to define the meaning of the word “friend?””

    It would in the context of a separate media type, ala application/vnd.ms.foo+xml

    comment at 30. July 2005

  3. Fredrik:

    That’s not how xml works, is it?

    What if you want to embed “foo” xml in an RSS feed? Or an XML document type that includes a “friend” tag? That’s the problem namespaces solves and a MIME type will not help. It will only move the namespace declaration from the root element to a Content-Type header (provided it is available).

    comment at 31. July 2005

  4. jcgregorio:

    I believe several key points are being missed in the rush to revulsion:

    1. In [1] I clearly state that there would be a registry for microformat extensions to APP collections, thus no squatting allowed.
    2. While I have argued that some things should be put into the XHTML content, I also believe that there is some stuff that clearly belongs outside of it, for example, the pub:control [2].
    3. I also believe that some RSS extensions should have been handled in content and not a separate namespaced element. How less functional is an enclosure element versus “a href='’ rel=’enclosure’” ?

    [1] http://www.imc.org/atom-protocol/mail-archive/msg01245.html
    [2] http://www.imc.org/atom-protocol/mail-archive/msg01242.html

    comment at 01. August 2005

  5. Robert Sayre:

    None of those are key points, because this post had nothing to do with your article or messages. (Didn’t mean to sound so irritated) It was only Tantek’s comment that I disagreed with.

    comment at 01. August 2005

  6. Anonymous:

    Wow, I had no idea it was you Robert that had posted that article. That explains a lot.

    comment at 01. August 2005

  7. more on microformats [@lesscode.org]:

    […] I’ve written previously on the trade-offs that microformats make in vocabulary design. I’m still not sure how I feel about the short-string issue, but it appears no one is waiting for me to make up my mind, so I figured I’d try it out. […]

    pingback at 04. September 2005

Leave a Reply

Note: None of this information is required but leaving a Name and URL is much appreciated. You can also register to have this stuff remembered.

Your comment can be previewed here.


Markdown: use the force, Luke.