W3C home > Mailing lists > Public > www-archive@w3.org > February 2009

Re: ISSUE-4: Versioning, namespace URIs and MIME types

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 19 Feb 2009 12:56:03 +0100
To: "Sam Ruby" <rubys@intertwingly.net>
Cc: www-archive@w3.org
Message-ID: <op.uplkrprc64w2qv@unknown-00-1d-4f-fa-48-ab.lan>

On Thu, 19 Feb 2009 12:40:07 +0100, Sam Ruby <rubys@intertwingly.net>  
> This problem is way worse with title, there the specs and consumers  
> (mostly) agree that it is plain text, yet the producers (mostly) agree  
> that it is entity encoded HTML.  That's why you might see things like  
> AT&amp;T in headlines.
> The only way forward in situations like this is to start over with a new  
> format.  People will never stop using RSS, but people who have a need  
> for the problems that Atom fixes will migrate.  And consumers will  
> support both.

I think RSS5 could have worked actually given that consumers presumably  
have some interoperability or can get aligned because of the feeds already  
deployed. It was mostly for political reasons that such an approach was  
abandoned though presumably also because it's less hassle to simply start  
over and leave the mess to implementors. (See also design motivations for  
e.g. XForms.)

Fortunately RSS/Atom is a rather simple problem space. (I read up on all  
the history, blog posts et cetera, but still, it's rather simple; no  
layout, DOM, etc.) Therefore having several different formats is not much  
of a hassle. (Then again, Google Reader still does not support Atom ID or  
handles redirects properly, etc.)

I also think that Atom only marginally improved things. It defined  
handling of the supposed problems with RSS quite ok (though complex). E.g.  
embedding HTML. However, requirements on how to handle invalid input  
(apart from XML layer errors) are missing.

Anne van Kesteren
Received on Thursday, 19 February 2009 11:56:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:33:34 UTC