[microformats-discuss] Evaulating RSS per the microformats principles.

[Tantek Ç elik]

On 8/12/05 8:11 PM, "Ryan King" <ryan at technorati.com> wrote:

> On Aug 12, 2005, at 4:45 PM, Michal Migurski wrote:
>>>> This same idea came up in #microformats the other day, with no less
>>>> than three people having independently invented it.  Given that you
>>>> guys are two more, this is about as unambiguous as a zeitgeist can
>>>> get: it's a great idea.
>>> 
>>> I would be one of those 'independent inventors'. :D
>>> 
>>> Basically, what I want is a microformat for blogs. I think there's
>>> enough similarity among blog markup to warrant trying to develop a
>>> format.
>> 
>> Isn't RSS already a microformat for blogs?


RSS is not a microformat for numerous reasons.  From a design perspective,
RSS violated many microformat principles.  Of course RSS pre-dates that
specific collection of principles so this is no fault of RSS in particular,
nor of anyone who worked on it.

However, overall RSS is a mixed-bag.  It actually does exemplify a few of
the microformats principles, which makes it an interesting beast to study.

So let's take a quick look at the principles and how RSS followed/violated
them:


* solve a specific problem
 - RSS certainly solved the specific problem of syndicate small bits of
content. So +1.

* start as simple as possible
 - RSS started pretty darn simple.  Maybe not as simple as possible, but
clearly the focus was there in spirit as well as in name "Really Simple".
Another +1.

* design for humans first, machines second
 - RSS definitely failed this point.  RSS was all about machine parsing,
with none or at best a secondary or tertiary focus on being designed for
humans. -1.

* be presentable and parsable
 - Sort of but not really.  RSS suffers from the same problems as most
"generic XML" data format efforts in that the format designers were not
visual designers and certainly gave no affordance for how the format would
"look" on its own or in a browser.  That didn't matter.  RSS was supposed to
be consumed by specialized programs which then transformed it into some
other presentation.   People have tried to visually style RSS with CSS with
mixed results.  Regardless, RSS doesn't satisfy this principle.  Another -1.
 
* visible data is better than invisible metadata
 - RSS is mixed on this.  Many features of RSS are designed to be visible
(item content obviously), and many features of RSS are designed to be
invisible metadata.  Overall a wash.  +0.
 
* adapt to current behaviors and usage patterns, e.g. (X)HTML, blogging
 - RSS didn't use XHTML, but it did try to adapt to and model current
journaling/blogging behaviors. +1.
 
* reuse building blocks from widely adopted standards
 * semantic, meaningful XHTML.
  - RSS didn't reuse XHTML (e.g. why <item> when <li> will do?), much less
*semantic* XHTML. -1.
 * well established schemas from interoperable RFCs
  - RSS makes no mention of pre-existing syndication/blogging/journaling
standards. E.g. the VJOURNAL object in iCalendar and vCalendar predated RSS.
RSS could have simply been an XML version of VJOURNAL.  Another -1.

* modularity / embeddability
 - RSS tried to be modular.  E.g. today's RSS extensions. BUT, RSS totaly
failed to be embeddable.  So either +1 and -1 or an overall wash. Let's say
this as a +1 and a -1 for sake of tallying.

* enable and encourage decentralized and distributed development, content,
services 
 - RSS was definitely designed to encouraged this, and by all accounts has
succeeded in doing so. +1


Total (unscientific:) score:

principles followed: five +1s
principles violated: five -1s
principles neutral: one 0

Having written this in one pass, I'm actually a bit surprised the that score
evened out like that.  RSS followed as many microformats principles as it
violated.  I find that very interesting.

Another interesting point is that if you look at the principles that RSS
*did* follow, you will see some of the core reasons for its success:

* solve a specific problem
* start as simple as possible
* adapt to current behaviors and usage patterns, e.g. blogging
* modularity
* enable and encourage decentralized and distributed development, content,
services


Let's not forget that RSS has taken *YEARS* to succeed and be broadly
adopted.  

Some of the (perhaps avoidable) barriers which may have slowed its
acceptance can be illustrated by the principles RSS violated, written here
as their opposites, i.e. counter-principles:

* design for machines first
* be parsable and ignore presentation
* use generic XML and ignore semantic, meaningful XHTML
* invent new terminology and ignore established schemas from interoperable
RFCs
* establish a new top-level container/envelope format that's not designed to
be embedded itself.

Of course there were other barriers (political, social, "personalities") to
RSS's adoption which could have perhaps been avoided as well, but very few
of those have to do with principles of any sort.


I've been thinking of writing this up as a blog post / essay, but since the
question came up here, it seemed appropriate to write it up here.

Thanks,

Tantek