Some people have probably noticed it already. Either on some other weblog or in a comment on this one. Anyway, there is now a RSS 1.1 specification (draft). Personally I like the idea of having a choice and cleaning up specifications (this is an update to RSS 1.0) is a good thing in my humble opinion. Some things I noticed:
CHANNEL uses a capital ‘C’ for the tag names.
CHANNEL element to be named FEED. In the RSS 1.1 namespace of course, not the Atom namespace.
application/rss1.1+xml.
AddType application/rss1.1+xml .rss1.1.
You might have noticed that HTML is not allowed. Don't worry; use the RSS 1.1 Payload Module to be able to use XHTML semantics in the feed. By the way, how many user agents would actually implement section 7.1? Considering that most aggregators are already using some kind of liberal feed parser I wonder if they are actually going to stop processing the feeds.
I think the format should have its own MIME type. Proposal: application/rss1.1+xml.
Inventing new MIME-type for every revision of a format, is IMHO, a huge mistake. See section 14.1 of RFC 2616:
accept-extension = ";" token [ "=" ( token | quoted-string ) ]If you used this extension, a client could send an Accept:-header that looked something like this:
Accept: application/rdf+xml;q=0.7;rss=1.0, application/rdf+xml;rss=1.1
A yes, such a thing might be more useful and has the same possibilities, right?
I am wondering a bit about application/rdf+xml though. Phil told me some people do not really like it. It can also not really be used as a MIME type for feed autodiscovery since RDF people might already have an alternative file that is not a feed.
Again, adding a ;rss=1.1 to the end might solve that as well.
Re: section 7.1: BRILLIANT! It's about time this came about. Ultra-liberal parsing (and non-standards compliant HTML and the browsers that grok them) hurt everyone, in the long run.
Oh great, yet another syndication format to add to the mix! I wonder how incompatible this one is?
By the way, adding version numbers to MIME types doesn't really seem like a good idea and, AFAIK, has never been done for any MIME type before.
I have to completely agree with Lachlan here, we don't need yet another syndication specification.
Although I have to admit that I didn't study the specification too thoroughly, since Anne is proposing a new MIME type I presume RSS 1.1 is not backwards compatible with 1.0, which just makes it even worse!
I'll just stick to Atom for now...
Lachlan, ECMAScript for XML uses such a paramter extension. (;e4x=1)
Charl, this is an update to RSS 1.1. My MIME type proposal was based on the fact that such things should be auto discoverable, but I guess a parameter would be better.
Lachlan, ECMAScript for XML uses such a paramter extension.
So does XHTML+Voice, but I don't think Lachlan was referring to a parameter; he was, I think, referring to a version in the type-name itself.
XHTML+Voice uses a separate MIME type. It does not use a parameter. You could be right about the second thing though.
Anne: That's also how I understood it originally. Anyway, I just took a more in-depth look at RSS 1.1, and I can now honestly say that I still don't see the advantages above Atom.
Charl, there is no advantage, there is choice. And this time it is a sensible choice, not some weird format like RSS 2.0.
Sensible? When there's a much better format available?
I don't have anything against choice and freedom - I'm really much for it. However, I can't see the sense in people just doing their own thing instead of working together on one good specification. It's not like there's something terribly wrong with Atom, and it's not like RSS 1.1 is highly innovative or anything.
If everybody just go off and do their own thing, what's the point of the web and of standardisation in the first place? It's almost as bad as going proprietary IMHO.