A pungent mix of programming, philosophy, pedanticism, procrastination, perplexity, peripheral political polemic, and platters of preposterousness.
Frederick Giasson has been working with a developer called Rob Cakebread on getting DOAP data available in RDF for Freshmeat projects. The DOAP descriptions are being used to help Gentoo developers keep track of project releases. There are teething problems (content mime-type), but it’s great. Another 43,000 resources added to the Semantic Web.
Another note for those awaiting the PHP OPML blogging server: I’m having metric crap-loads of trouble with character encoding. I want to support Unicode (UTF-8), but the OPML Editor turns out ISO-8859-1. There’s no easy way to get the character encoding stuff to work seamlessly, especially if you don’t have full control of what’s going on with things like the blogging clients. The silly thing is that XML should make thinking about character encoding irrelevant. Alas, not yet…
I’ve found the clearest reference for the MetaWeblog API to be this guide on MSDN. Stick it in your bookmarks in case you have to implement MetaWeblog API…
Another test of XML-RPC posting.
Adam Green: “Dave’s contributions sometimes get erased from technology history, but he should know that with Twittergram he has definitely nailed it again. I can see everyone from Iraq war correspondents, to Paris Hilton, to Osama Bin Laden adopting this technology. Whether it is used for good or evil, this will create another medium to go along with blogging, RSS feeds, and podcasting. Not a bad record.”
Kevin Marks has implemented hAtom on all BlogSpot blogs! You should consider hAtom too. I have it as implemented as I can, but I can’t fully implement it because I don’t title most of my posts (and Atom feeds should have titles or something).
If I were to tell you that since most people don’t vote for third-party and independent candidates (or rather, candidates that are not from one of the two main parties) in the United States presidential election and, as a result, the Federal Election Commission or other government agencies dedicated to running elections had decided to block them from running, you would be somewhat outraged. This is practically, if not intentionally, the case with the complex situation over ballot access in the United States. Nobody really thinks it’s a good idea. At heart, we have a sort of Darwinian-democratic idea that if someone wants to run for President, it should be a level playing field. If that means Bob Smith from Nowhere, Iowa, goes on the ticket next to big-name politicians like George W. Bush and Hillary Clinton, so be it. The price of democracy (and capitalism) is that there’s never any deficit in choices.
In the adoption of “pave the cowpaths”, a difficult philosophical position has been taken by certain people involved in standards design with which I have to strongly disagree. It mirrors quite closely the situation with ballot access.
The “pave the cowpaths” philosophy can be a good thing - if one realises it’s limitations. If there are no existing standards, and it’s a choice between a path which a lot of people are using and a path which nobody is using, then it’s definitely a good idea to pave the one which most people are using. This can be through the official process of an organization like the W3C or the IETF, or perhaps through an unofficial but well-respected process like microformats.
But there are situations where you are not making a choice between two otherwise uncharted routes. If you have a standard already in place, you have to make decisions as to whether to deprecate features. Here, pave the cowpaths has some use, but it needs to be held in balance with other design philosophies. If the continuation of a feature or design pattern will dramatically increase the value for the end user, that’s a good point. If the deprecation of a feature or design pattern will make the lives of users better, that’s also a point in it’s favour. If something is actively causing harm to the user’s experience, then perhaps it should be dropped.
If there is already a paved highway there, and users have chosen not to start using it, that doesn’t necessarily mean we have to dig it up. It may be a perfectly good road, and all that is needed is for some advocacy and good design. The example the usability people bring up is MP3 players. The early MP3 players like the Diamond Rio back in the strange old years of MP3.com and so on, were not that usable or popular. Eventually the iPod came along, and, well, we all know the story. Thankfully, this potential cowpath was not shut off, and the market was free to come up with more innovative products. One of the most boisterous and clumsy standards body in the world - the U.S. legal system - could have shut down this particular cowpath before it happened.
Another example is CSS. From the time when CSS was first touted and the initial standards began to be drafted, there was a long way before it finally became popular. It would have been quite easy for those in charge of the process to say “Meh, nothing’s really happening with this CSS thing, so let’s just shut it down now”. Thankfully, they persisted. It’s not all the way there yet - there are still browser implementation issues and crazy, irritating bugs - not to mention sanity-deprived teachers who, well, penalize students for using web standards. If you went back to 1998 and paved the cowpaths, you would have paved nested tables. If that which is popular is, by definition, good then we don’t need to work for standards. If a strong version of “pave the cowpaths” is what you work to, then you should be advocating shutting down WaSP, SpreadFirefox and any other organisation or effort to advocate for making the Web better. I mean, the cows have chosen FONT tags, inaccessiblity and Internet Explorer 6, so why bother trying to advocate for anything better?
As Mike-O-Matic puts it: “New programs are a chance to get things right and should be used as an opportunity to ask the challenging questions about why things are the way they are and what can be done better.”
What this is driving at is that something’s popularity is not sufficient to merit it’s continuation, nor is it’s unpopularity sufficient to deem it irrevocably evil. One would have thought that this would have been figured out by anyone who has left their teenage years. Sometimes doing the right thing will make you unpopular.
Which brings us back to the profile attribute. I’ve spilled enough electronic ink over this little beauty. It allows anyone to extend the semantic capabilities of (X)HTML. It means I can come up with an idea, and I don’t have to persuade the W3C or Tantek in order to put it out there. And if you prefer to do it differently, you can grab yourself a different URL and do it your way. XML’s extensibility brought to the Web. It’s the same kind of freedom that voting for a third party candidate brings - it may make no difference in the end, but not being able to do so frankly sucks.
Sure, profile isn’t perhaps the most widely used of features in HTML. But that doesn’t matter. No harm comes from it’s continued existence. It’s use cases may be niche - at the moment - but keeping it around is another hook for scalable innovation - that is, innovation without having to get permission. Close up those little pokey holes where people can play and experiment, and you lose a lot of potential future cowpaths.
If we wish to have a design philosophy for the next generation of the Web, may I humbly suggest: Pave the cowpaths, but don’t close off access to potential cowpaths. The great strength of HTML is that it’s flexible and allows you to extend it using class-names, attribute values and URIs!
