Slashdot Mirror
Google Finally Moves Toward RSS Standard
declan writes "My News.com colleague Evan Hansen just got his hands on an internal email thread revealing that Google is planning to embrace RSS. Evan's co-authored News.com article quotes from the email (sent to Sergey Brin, Larry Page, and Eric Schmidt) confirming that Google is rethinking only supporting Atom. Slashdot covered Google's purchase of Pyra Labs and Blogger.com/Blogspot.com last year that made it a fan of the Atom standard. Does this news mean that RSS is now viewed as out of Dave Winer's control? Will RSS and Atom finally converge?"
RSS and Atom files provide news updates from a website in a simple form for your computer. You read these files in a program called an aggregator, which collects news from various websites and provides it to you in a simple form.
the IETF just approved a new WG whose charter says:
The working group will use experience gained with RSS (variably used as a name by itself and as an acronym for "RDF Site Summary", "Rich Site Summary", or "Really Simple Syndication") as the basis for a standards-track document specifying the model, syntax, and feed format.
The name of the group is ATOMPUB, so you see where the rest of the experience being considered comes from.
Hopefully google will adopt RSS rather than Atom. I don't know why but I've always preferred RSS. Incase you are thinking WTF here are some links courtesy of Wikipedia:
RSS
Atom Note: These pages are a bit thin on detail but contain some useful links if you want to find out more
I think the deficiency with RSS was lack of a consistent implementation. There were too many minor variations within the assorted RSS instances to guarantee compatibility from one to another. Atom had the advantage of being self-consistency.
If a job's not worth doing, it's not worth doing right.
At this point everything is "proposed" and saying these are not "protocols" and just "vocabularies" and RFC is not appropriate.
There are some geek-muscles being flexed about in RDF/RSS and people want to maintain control over it (same with FOAF, which I am dealing with often) that is why the Atom guys came up with their own, it is a rewrite they came up with that addressed problems they had been reporting/asking for fixes for (or at least extensions for) for quite a while to no avail.
Anyway, it is a big pissing contest still, if google jumps in and picks a side, it is game over.
anime+manga together at last.. in real time.
LiveJournal has atom feeds enabled for all of its accounts.
Here's for example, ATOM feed from my account (don't read it, it's in ru-ru anyway), and if you change the username, you can get anyone's ATOM feed.
As far as I understand things, besides personality issues, the Atom folks were looking for more i18n and for a more-specific standard --there are tags in RSS who are being (mis)used differently by different content-producers exactly because the spec was not very clear from the beginning.
As an RSS producer/consumer myself, the one thing I've always hated about RSS was the encoding of the description tag: some feeds escape any HTML included in description, some make the whole tag a big CDATA entity, and in any case there is no information provided as to the encoding of the included HTML. One of the side effects has been that if you are parsing RSS, you have to assume that description includes HTML. So, if you happen to have > or < or any other HTML-looking entities within description, your content will be mangled by the RSS-consuming code.
I'm a member of the RSS Advisory Board along with Dave Winer and several others. What do we have to do to convince people that it isn't controlled by Dave Winer or anyone else? Read the license for RSS 2.0. The specification is released under a Creative Commons license and no ownership is claimed of the format embodied by the specification.
Rogers Cadenhead (Web: http://www.cadenhead.org/workbench)
For anyone interested in the tag differences between the two feeds, look at the simplicity of the RSS feed compared to the noticeably more complex Atom feed. The difference will probably enlighten many people, as it did me, about which information is more useful. It seems that they have jammed a whole lot more attributes into each element. The usefulness of that information can be dubious at best, however.
RFC stands for Request For Comment.
An RFC does NOT have to be a standard, it does NOT have to be binding. It CAN be a memo about an idea that you want others to COMMENT on, it CAN be a proposal for which you are REQUESTING others people's COMMENTS.
Hence, the statement "RFC is not appropriate" is incorrect.
Sig Heil: Scumerica - Land of the Free* (* 18+, valid papers, health insurance, some restrictions apply)
Pretty handy.
umm..
I was not going to respond to this.. but just in case someone else might happen to think you are correct for some strange reason.
If you actually poke around in RFC's you might notice that languages generally don't have them (markup does, but XML which is what RDF/RSS/Atom is built on already has an RFC).
Poke around http://www.faqs.org/rfcs/ and see, you are generally trying to have top-level projects for RFC's, not a subproject.
RSS is a vocabulary built on XML and therefore would never warrant an RFC.
anime+manga together at last.. in real time.
Surprisingly, none of them are that great to use IMHO...
I like Amphetadesk myself though. It basically combines your feeds into a simple webpage and views on whatever browser/OS choice you use. (Well, Windows, MacOS and Linux at least)
Yahoo News has a free RSS service
but he is correct. an RFC is a request for comments. you can put them out for just about anything you want other people's input on and it would be appropriate. common usage is for high-level specs, but RFC still means RFC.
An example of underspecification? The RSS 2.0 specification says that the <description> element may contain escaped HTML. In previous versions, it contained plain text. RSS 2.0 has to allow plain text to maintain compatibility with previous versions.
So what happens when somebody includes escaped HTML special characters in their description element? Do they intend the element to be treated as HTML or are they simply talking about HTML or something else that uses angle brackets?
There is no way of knowing.
People proposed a type attribute to fix this. They were ignored. Then Reuters had a problem with this issue, and Dave Winer scrambled to fix it, after ignoring everyone else's pleas for fixes to this problem.
Popular public RSS readers have generally treated all instances of <description> elements as escaped HTML. This doesn't usually break anything.
Now they are proposing to fix this issue by requiring escaped HTML. Great! That means the ambiguity has gone.
The only trouble is, they made a big song and dance about how RSS 2.0 is backwards compatible and that there wouldn't be any changes to it. They can't fix this issue without changing this.
It's worth changing, right? Sure. But Dave Winer doesn't want to lose face after attacking other "unstable" specifications. So they are sneaking it into the specification as a "clarification". It breaks backwards compatibility. It's a substantive change. But they are spinning it as imprecise wording, which is a total lie.
The situation isn't helped because Mark Pilgrim noticed this break in backwards compatibility, and pointed it out straight away, providing a test case of a feed that would be broken by this change.
Dave Winer and Mark Pilgrim dno't get along.
Dave Winer, who is constantly claiming he does not control the RSS specification, deleted Mark's comment and testcase from the feedback to the advisory board.
Personally, the specification is bad enough, but the attitude of Dave Winer makes the RSS specification untrustworthy. You don't know what changes he's going to sneak in next under the guise of "clarifications". You don't know if he's going to delete objections people raise.
Well, not really; XML is a recommendation from the W3C. The W3C is not a standards body. It is a vendor consortia.
The W3C puts out specs that it expects vendors and developers to agree on and work with. If all goes well after some period of time then it may be worth moving the spec onto a standards body, such as ISO.
Sadly, the word "standard" has become a substitute for "specification. Hence you hear about the Java(tm) "standard", the Atom "standard", and so on. Everytime somebody puts something down on paper they say, "Hey, we have this new standard." But it makes for great marketing to say, 'Oh, we're all standards-based.'
Java is the blue pill
Choose the red pill
That's already happened. When Reuters launched its RSS feeds two weeks ago it was valid as per the RSS2.0 specification, but every news aggregator failed to display the stock-ticker names within the feed. Silent data loss.
What is unfortunate, from an RSS perspective, is that this problem has been known for quite some time. Previous efforts to correct this problem were mired (one of the factors that lead to the Atom initiative). But it took a public failure of Reuters feeds before the RSS folk took it seriously enough to think about discussing it. So far, with the help of Mark Pilgim and aggregator authors test cases have been established for this particular scenario.