Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and get your project in front of SourceForge's nearly 20 million monthly users. It takes less than a minute. Get new users downloading your project releases today!
heeeraldo writes "Is there another format war on the horizon? This wiki compares the two, and finds that even though RSS has far greater deployment (and mindshare), Atom 1.0 solves a lot of the problems associated with it."
This discussion has been archived.
No new comments can be posted.
Not exactly true. Microsoft have confirmed that their Longhorn RSS plans does include handling Atom. They have thrown their weight behind RSS as in syndication, not RSS as the file format.
This isn't trolling, just confusion. I would consider myself to be relatively informed about tech matters, however there is very little info about atom and it is hard to google for. Would it be possible to have a tiny summary as to what atom is ?
RSS and Atom are standardised ways of having a live list of stories appear from say a newssite (like this one) in various programs. Firefox calls these live bookmarks. I came here using firefox by clicking on my toolbar, seeing all of the new stories, and deciding I was interested in this one. You can also use it for desktop "news ticker" applets.
The trouble with RSS (short answer) is that there are at least three different versions of it invented by different people. As far as I know there was an RSS 0.7, then someone else invented a new protocol and called it RSS 1, then the original person invented RSS and called it version 2, but some people argue 2 is worse than 1:(. All of these standard's owners have been accused of not taking on board comments from the wider community.
Atom is another protocol for doing the same thing. Technical issues aside, it gets my vote because they didn't decide to call it RSS 3. Or RSS 10.
The claim that there are multiple incompatible versions of RSS is used as a way to try to make RSS look bad. I've written code to interpret an RSS feed, and I don't have any switching based on the version of RSS it is... I do have to figure out what to use as a unique identifier based on some heuristics, but that's not because there's multiple versions, it's because the spec intentionally allows you to include a minimum number of tags.
If you don't like something about a protocol, is the correct thing to
As far as I know there was an RSS 0.7, then someone else invented a new protocol and called it RSS 1, then the original person invented RSS and called it version 2
No. The short version is that somebody at Netscape invented 0.9something based on RDF. The public release (another 0.9something) was rushed for my.netscape.com and wasn't based on RDF. Then Netsca
This is very interesting because I never realized the parallels between RSS and HTML standards. Consider all the changes between the various HTML standards. Considering this is slashdot, I won't go into extreme detail. A little reading on w3.org, etc. will clarify for those that do no know.
The w3 refactored HTML 4.01 into XHTML 1.0 using XML instead of SGML. This is similar to the RDF to standard XML change in RSS. Then, the w3 modularized XHTML 1.0 Strict into XHTML 1.1, similar to the back and forth
Well, these are are XML syndication formats. In other words, they move headlines and article summaries from server to user in machine-parseable format.
There's RSS, which is the reigning de facto standard, but it also is regrettably very, very liberally specified, and even less frequently heeded. Everyone's extending it to their own heart's content more or less competently. There are lots of different variations. Not easy to implement, not easy to learn.
Atom is an attempt to make a real standard-like sta
Either that article is heavily biased or ATOM 1.0 completely demolishes everything that RSS is/was/used to be. I wish that the article would have at least showed one or two points where RSS is better, but it appears that there isn't any such points.
Well, of course! Click on the Front Page [intertwingly.net] link, and Voila! You are on the Atom development wiki. This is hardly an unbiased discussion.
The RSS 2.0 specification is copyrighted by Harvard University and is frozen. No significant changes can be made and it is intended that future work be done under a different name; Atom is one example of such work.
This is the point: Atom is just a fork. RSS is a real concept. Forks come and go, a concept stands.
Yeah, I know what you mean. I don't understand why anyone uses OS X, Linux with KDE or Gnome, or Windows XP nowadays. Those are just forks of the original GUI concept. Now the Xerox Alto computer, that was a concept and its the only thing I trust to last.
Atom isn't forked off of RSS, it's another implementation of the concept of syndicated content. RSS itself isn't a concept, it's a specification for a data transfer format.
The parent post really doesn't make any sense at all.
Either that article is heavily biased or ATOM 1.0 completely demolishes everything that RSS is/was/used to be.
I'm sure it could be argued OGG Vorbis completely demolishes everything that MP3 is/was/used to be also, but does it matter? Like MP3, RSS has already won the mindshare war. Those three letters are already stuck in the minds of bloggers as the very definition of How To Syndicate Content.
Back to the VHS Vs. Betamax days eh? If there's one thing that war proved, it's that technical sophistication is irrelevant: mindshare is what matters. If nobody's using it, it doesn't matter if it has the prettiest widgets.
That said, one nice thing about this format war is that there doesn't have to be a loser. It's fairly easy to handle multiple formats in software (note the number of redundant music formats), unlike hardware which is usually impossible. If the process of reading RSS tags or Atom tags is made transparent to the user, who cares who wins?
The difference, in this case, is that the decision to use RSS or Atom will be made by the website operators, not the end consumers. The consumers will use what the webmasters use. And I'm thinking that the webmasters will be attracted to the features rather than the ubiquity of a particular format.
IE supports enough PNG functionality to be able to do anything you could do with JPEG, and more. It just can't do proper transparency, which JPEGs don't support either.
I think the fact that JPEG (1985) has been around for many more years than PNG (1995) and the fact that Unisys was collecting LZW (used by PNG) licenses from 1995 to 1999 also have something to do about that.
In any case, the majority of sites I visit still use GIFs (1987) for generic elements, like the rounded end on separators and story icons here.
AFAIK, PNG was never aimed at replacing JPEG... its main aim was to provide a better, Compuserve-free GIF alternative.
Doh! (I should avoid speed-reading so many things at once. BTW, it seems IBM also has a LZW patent due to expire next year.)
In any case, GIF is still the most common generic site image format on the sites I visit so I do not quite see this alledged favourism in action. Maybe there is a study somewhere with actual online image format statistics that would say otherwise.
And with GIF's liberation (or even throughout the Unisys/Compuserve episode), most site designers/maintainers simply applied the good old "
[...] if not for the right reasons. [...] With the expiration of the LZW patent it's not really a "GIF replacement" anymore
Looks like you did not notice the past tense in "its main aim was to provide a better, Compuserve-free GIF alternative"... back when PNG first came along, this _was_ one of the reasons, even if it no longer is _now_.
I did indeed notice it. That would be why my first sentence after your quote was, "You're right about this though". I added the "for the wrong reasons" because "Compuserve-free" is not entirely accurate. Unisys was the patent holder on LZW, not CompuServe. CS licensed it from Unisys to make it available for their users in the GIF89 format, which is why it became associated with CompuServe but they weren't technically the "bad guys' here. CS didn't control L
That's a completely back asswards way of looking at it. Website opperators are forced to cater to broken IE implementations not because they are attracted to its features, but because that's what 80% of their visitors are using. And no, if you're a commercial website you can't just say "Screw 'em if they're not smart enough to use Firefox."
So back to the original point, if no one is using Atom, why would website operators publish in Atom? Though I do agree with the point that's been made that it's easy
The choice is left to the web site developer's preference because, generally, modern RSS/Atom aggregators can support both formats. The end user doesn't really need to know or care what format the information is provided in if they can handle both.
The difference, in this case, is that the decision to use RSS or Atom will be made by the website operators, not the end consumers.
You are right about that to the point that the web site owners decide what format to use...
The consumers will use what the webmasters use.
Now that is mistaken. The consumers will use what the consumers use. I know that sounds redundant, but consider - Safari already has built in RSS support. IE will have built in RSS support. So how many consumers will actually use Ato
I use Sage [mozdev.org] for my reader, so I really don't care what format feeds are in. Actually, I never researched the differences, so every time I had a choice between Atom and RSS feeds from the same source, I always chose RSS, because I thought Atom was an older style, and also thought that if I ever switched to another reader, it'd be easier to move my feeds if they were all RSS.
Please tell me you didn't really mean to imply that all technical sophistication has nothing to do with user functionality and ergonomics;).
Certainly not.:-)
But then (at least to my mind), "pretty widgets" doesn't imply user functionality and ergonomics, either.
I think we agree: a product with great technical sophistication can be killed by a bad user interface (which is also technical to some extent), but lack of effective marketing to bring the product to peoples' attention can make both irre
If this was a VHS versus Betamax style debate than one standard would be proprietary and carry heavy licensing fees. That, and the shorter recording times, are the reasons why Beta lost out to VHS. This issue is simply a question of whether or not a derivative standard improves on, and thus should replace, a previous standard.
It's fairly easy to handle multiple formats in software
How true...I never run into problems trying to get CSS1 and CSS2 to work properly across IE/Safari/Firefox/Konqueror/etc. Granted, some of them implement the standard improperly (*cough...IE..*), but this is what happens when multiple standards exist for the same purpose. I for one don't like re-creating my work for RSS 0.7/1.0/Atom/whatever...that's 3x the work I have to do. And then we'll get RSS 10.0...
If the process of reading RSS tags or Atom tags is made transparent to the user, who cares who wins?
That's right - if they do the same thing noone cares.
I suspect somebody clever will come up with a killer app that will require a feature that either one or the other has that we're not noticing right now, and then noone will remember the other format. As it should be.
Atom is both a syndication format and an API [bitworking.org] for creation, updating, and deletion of content. It's already in widespread use by Blogger.
What's been (all but) finalized is the syndication format (and rules for extending it). This allows the working group to firm up the details of the publishing API, which, for my money, is the real payoff with Atom.
A pretty good overview of the history of RSS and the motivations behind Atom is here [computer.org].
While the article was a nice feature comparison of the two, it really didn't get into the "format war" question at the top of the page here.
Besides industry support, my only question would be "which one is growing?" Which of these formats is expected to get a new version number sometime soon?
If you ask me, that is why Microsoft is talking about adding "extensions" to RSS -- by growing and adapting the standard, it gets more bells and whistles, more application support, and more momentum in the development community.
....some moron has defaced the page already (and is apparently deleting archived hostorical versions of it).
Life expectancy of unlocked Wiki page when slashdotted: 15-20 seconds.
AFAIK the format war between RSS 2.0 and RSS 1.0 hasn't even ended yet. In spite of the version numbering, RSS 2.0 is more of a.95 than a 2.0 since it's an incremental improvement over.94. It doesn't really add any capabilities to RSS 1.0 (both can support enclosures). The only real difference is that RSS 1.0 is based on RDF while 2.0 isn't; this supposedly makes 2.0 simpler, but potentially less capable.
It's a pity that all the RSS folks couldn't simply hash together a common standard rather than wasting time on competing standards. Is 2.0 really that much simpler than 1.0? Is 1.0 really that much more capable than 2.0? Does Atom really add much to the mix? It seems that it ought to be possible to find a middle ground.
The problem with RSS 1.0 is that it is more complex than RSS 9.x (a designation which should include "2.0"), this is caused by two design decisions:
RSS 1.0 is infinitely extensible because it can be combined with other RDF schemas. In order to extend RSS 9.x, the standard must be extended. This allows its expansion to be controlled, which seems more managable, but as time goes on, features get duct-taped to it in ugly ways.
Because of RSS 1.0's extensibility, its syntax is less human-friendly. This was an
It's a pity that all the RSS folks couldn't simply hash together a common standard rather than wasting time on competing standards. Is 2.0 really that much simpler than 1.0? Is 1.0 really that much more capable than 2.0? Does Atom really add much to the mix? It seems that it ought to be possible to find a middle ground.
Without getting too much into the politics of the syndication world, the reason is that no-one wants to touch RSS 1.0 with a ten-foot pole (even without the bitterness and fallout fro
One thing that really bothers me about RSS, no matter how much I like it, is how every site uses it differently. I was writing a simple aggregation program and using php/magpierss. Every single site puts the date and time of the items in a different tag. Some use datetime, some use pubdate, some use dc->date and some don't put the date! Seriously, no matter the standard it wont help if not everyone uses it fully and properly.
That's because RSS 9.x (which should include "2.0") has a very similar design philosophy to Perl. It's not supposed to be elegant, it's supposed to do whatever needs to be done to work ASAP. It's also writer-friendly over reader-friendly.
RSS 1.0 is slightly more complex but a gajillion times more elegant. It has actual standards for metadata [resource.org].
I've got an open source aggregator (<plug mode="shameless">Feed for Mac OS X [keeto.net]</plug>) and it seems most of the 'bug fixes' I have to do are directly related to some fools home-grown interpretation of how to deliver content.
Effectively, RSS (the concept, not the format) is in the 'tag soup' phase that the web was in seven years ago. While I expect this will all settle down as the concept (and value) of standardization is realized by content publishes and CMS vendors, it cu
For the most part it doesn't matter which you use because client software is going to have to work with both now that they've both been deployed (and for a while Google was only publishing Atom, I'm not sure if they still do that but it forced aggregator developers to get on board).
But because an Atom feed must include a guid element, the client has a way of uniquely identifying an item. This means that when you subscribe to an atom feed, you're not going to see duplicate articles the way you do with RSS when the RSS feed doesn't include a guid or any unique identifier (which is legal) and the client has to make one up by hashing the content.
as long as rss doesn't require you to at least include blank versions of standardized tags we will have the same problems that html has. lots of people out there writing bad code that don't work well for the diversity of readers.
Most of the problems with RSS 2.0 that the article points out, are fixed in RSS 1.0.
For those who don't know, RSS 0.9x was basically Dave Winer's personal plaything. When the standards community put together an RSS 1.0 standard, he took his most recent 0.9x 'standard' and renamed it RSS 2.0 to make it look more up-to-date.
Why not take RSS 1.0 and fix the few problems it has?
Does RSS 1.0 have any problems that aren't inherint to RDF? And does RDF have any problems that aren't caused by expressing it in XML?
Sure, RSS 1.0 takes more work to understand up front, but once you get RDF isn't it just another schema? And these days, now that blog software has automatic feeds and there are aggregators available on every platform, how many humans actually need to read it?
Congratulations, you Get It:-)...Atom gives you more-or-less the same thing
Um, wow, thanks.:) But why support Atom if it isn't RDF? It's a shame the community got fractured in the first place, but it seems like the powers behind Atom + the powers behind RSS 1.0 are enough to tell Dave to stop whining.
We can go on and on about the Atom and RSS war. But let me introduce you to something that uses the power of both. Please note that I'm not advertising my site.. I'm talking about Newster.net [newster.net] only because it is very relevant to this discussion.
Newster is aggregatates news from many websites that publish them in RSS. Once the news bits are in the database it uses the ATOM API to post it to the blog. And then it republishes it in ATOM (because its a blogger service). So what we have here is a website that p
Has anyone noticed none of these standards have any form of e-mail obfuscation, or any support for contact methods that protect publishers from harvesting?
Atom wins hands-down. Things are actually well specified [atompub.org].
I can just walk through the atom specification, implementing it as I go, and not have any questions about what is required, what type of content can be present in any one element, I don't have to look up five even less well-specified different modules just to get the basics of the feed together (and thus also don't have to worry about namespaces), what elements and attributes mean (actually, I spent a minor five minutes agonizing over what I should put in the term atribute of the category element, given that the label attribute contains the human readable version, before realizing that I was completely free in this, as the "scheme" os up to myself, and deciding to mirror how categories are named in the url on the website (which I found to be consistent with various other already existing atom 1.0 feeds [intertwingly.net] that I checked)), or... well, basically any kind of question that you need to think about as you implement a new and previously unknown specification.
RSS on the other hand (any of the 9 incompatible versions)... *shudders* Those specifications don't tell me anything. I copy/paste from other feeds and heavily use the feedvalidator [feedvalidator.org], but... *shakes his head*
Once all feedreaders have been updated to support Atom 1.0 completely, I'll go and pull the plug on the remaining RSS feeds, and good riddance too!
1) It was written by Mark Pilgrim, one of the major minds behind creating the specification for Atom. 2) Mark's a personal friend of mine, and I personally think he makes sense.
The point of the article is, however, that RSS is terribly broken and fragmented, versions aren't compatible with each other, and it's just a plain mess. Look further on his site and you'll see articles as to not only why he helped c
Is RSS 2.0 one of the Unlikable Paranoid Beardo Dave Winer http://www.memepool.com/Date/253/ [memepool.com] RSS formats or one of the rival RSS formats created to annoy Unlikable Paranoid Beardo Dave Winer?
The greatest advantage Atom has over RSS is indeed its eXtensibility.
So while RSS is stuck with regular HTML (escaped markup, whoa!) and images in its contents, Atom can already embed other XML namespaces like XHTML, SVG, MathML, FOAF, Dublin Core...
I think the comparison is similar to the HTML/XHTML one: though right now they can give the same results, in the (not so distant I hope) future Atom/XHTML will become the languages of choice.
Not a lot of people use XHTML+SVG yet, but with Opera supporting it
This comparison (on the Atom site, natch) misses one very important point, which is the rapid rise of podcasting and videoblogging. All of these "rich media" syndications rely on the <enclosure> tag, which is exclusive to RSS 2.0.
It's funny how this writeup doesn't even mention enclosures, despite the hundreds of thousands of people downloading content this way. The only place it comes up is in the chart at the end, which makes some side reference to <link rel="enclosure"> in Atom, which is
The only place it comes up is in the chart at the end, which makes some side reference to <link rel="enclosure"> in Atom, which is a far kludgier (and nonstandard) way to do things.
Atom has thought about rich media far more than RSS2.0. For example, one of the problems of podcasting is that popular podcasts require stacks of bandwidth. One solution is to offer a bit torrent link. RSS2.0 only allows one enclosure per item, so you can't offer both a straight download and a torrent.
I've recently "discovered" podcasting... i thought it was straight-old streaming MPEG audio (like Shoutcast plugin for Winamp, which enjoyed popularity a few years ago), but instead is RSS delivery of MP3 audio files - reminds me of when i was a kid and used to do my own "radio shows" on a dual cassete deck stereo. No different than posting the files online with a web server.
I just don't get it. Then again, i don't get a lot of recent computer trends... i'm turning 25, and already feel old.
Okay, people. Part of the point here is that this issue is still being decided.
With that in mind, please support Atom in your future projects. Atom really is a better user experience for end users, and it's better specified and easier to work with as a developer.
The RSS folks are great, and they've put in a ton of hard work, but the Atom spec is Just Better right now, and offers at lot more bang for the developmental buck, not to mention it handles feed aggregations much better.
That's a dumb comparison. Betamax would still be around if users and distributors weren't forced by economics to choose a single format. You couldn't buy a VCR that did both formats and the cost of supporting an extra format was too much for distributors. By contrast, most aggregators support both RSS and Atom, and its pretty easy to distribute in both formats if you have a mind to. The only issue is whether the extra features of Atom are worth bothering with.
You're soaking in it.
(Firefox has supported Atom since at least the first full release of the RSS support; the Sage plugin also supports Atom).
Kids, Atom's not new. It's been developed by lots of smart folks.
Slashdot has the most broken RSS feed ever invented. You get banned for 72 hours if you access it more than once every 30 minutes. Not really a problem, except that Slashcode is braindead at identifying individuals. Two computers behind a NAT are treated as the same person, for example. Worse, my ISP uses a transparent proxy for everyone in my city (most people here with broadband use my ISP, since their cable service is a lot cheaper than competing ADSL suppliers). Does Slashdot recognise this? No, they block the transparent proxy whenever more than one person using it accesses the site within a 30 minute period. Clever, huh? The result is that the Slashdot feed is always blocked for me at home.
"Two computers behind a NAT are treated as the same person"
"They block the transparent proxy"
The reason for this is because about the only thing you can't forge is your apparent, from the Slashdot server's perspective, WAN IP address. Your real WAN or LAN IP is passed in an easy to manipulate X_FORWARDED_FOR or HTTP_VIA HTTP header (both non-standard HTTP/1.1).
Of course, If you add a fake IP address to this header then a legitimate user-agent or proxy should still append you're remote IP. Although, I don
Are you behind a NAT or a transparent proxy (provided by your ISP)? If so, then you are likely, like me, never to be unbanned from the Slashdot RSS feed because it can't tell the difference between you and other people with the same IP.
Atom cleanly specifies how to incorporate plain text, html and XHTML content in an entry. Covering how text and html needs to be escaped, etc.
RSS2.0 had a problem last year where Reuters suffered a public embarrassment adopting the format. They followed the specification correctly, and it resulted in silent data loss - their stock identifiers were in angled brackets and got treated as an HTML tag by news aggregators.
It wasn't rocket science, but this simple thing turned out to be impossible to do with RSS2.0 - it was tried many times. After the funky feed debacle, the community realised that a separate format independent of RSS2.0 was the only way to fix the underlying problem.
The proponents of RSS2.0 tried to fix the silent data loss, and ended up breaking backwards compatibility with RSS0.92 - something they weren't prepared to do before Atom.
Well it's not being able to see news articles in one place thats the big deal. If you are someone that has a regular group of web sites you check every day, say Slashdot, Register, MSDN blogs, your ex-girlfriend's blog etc... you don't have to manually visit every site to see if content has been updated and if it interests you. You just glance at some feeds real quick to see if interesting content has been updated.
Because browsing around hundreds of web sites for news is a pain in the ass. Let the information flow to YOU. It's all about structuring the info so you can do more with it beyond simple screen scraping.
I'm not talking about just Dilbert comics or other entertainment outlets. Imagine notification of software updates. Email is lousy for this sort of thing when you get hundreds of emails per day. It's not searchable and it sits in your own account. Another benefit of RSS is control over the lists. You ever get an email from someone you know that didn't really come from someone you know, yet had a nice virus payload attached? This doesn't do that. Any info that comes from the RSS channel is something YOU have subscribed to and unsubscribing is dead easy.
Further, with an RSS Reader I use called Feed On Feeds [minutillo.com], you can access its mySQL backend from any other software to do what you want with the information streams. There are many other readers that use this same philosophy. If you MUST have mailing lists, well, then mail out from there; not all of these sites have mailing lists and this would make a great way to present it in that format. You can reblog select posts, or a channel combining a number of other channels.
Atom has the advantage of having a very well defined spec. The user agent doesn't have to guess if pointy brackets are content or markup. By using Atom, as a producer you will probably be better off, because you can trust the user agents to get it right. And for the same reason, it will be easy for user agents to support Atom (easier than supporting the numerous RSS variants) so there is little doubt every serious user agent will support Atom in the near future.
Can't tell the difference (Score:3, Insightful)
So, as a conclusion: Noone cares.
Re:Can't tell the difference (Score:3, Insightful)
Most users != Slashdotters
Re:Can't tell the difference (Score:2)
No question (Score:3, Insightful)
Re:No question (Score:4, Interesting)
Re:No question (Score:3, Interesting)
Re:No question (Score:2)
Re:No question (Score:3, Informative)
So all feeds supported in Longhorn will be:
RSS 0.9x
RSS 1.0
RSS 2.0
ATOM 0.3
ATOM 1.0
Re:No question (Score:3, Informative)
Correct (Score:2)
Re:No question (Score:2)
Microsoft said that they'd support Atom alongside RSS if it was finished before Longhorn. The Atom 1.0 RFC will be finalised any day now.
Neither... (Score:5, Funny)
http://blogs.msdn.com/ie/archive/2005/06/24/43239
Regards, Yogix
It's called namespaces... (Score:5, Informative)
I would consider... (Score:2, Interesting)
Re:I would consider... (Score:3, Funny)
Re:I would consider... (Score:5, Informative)
RSS and Atom are standardised ways of having a live list of stories appear from say a newssite (like this one) in various programs. Firefox calls these live bookmarks. I came here using firefox by clicking on my toolbar, seeing all of the new stories, and deciding I was interested in this one. You can also use it for desktop "news ticker" applets.
The trouble with RSS (short answer) is that there are at least three different versions of it invented by different people. As far as I know there was an RSS 0.7, then someone else invented a new protocol and called it RSS 1, then the original person invented RSS and called it version 2, but some people argue 2 is worse than 1 :(. All of these standard's owners have been accused of not taking on board comments from the wider community.
Atom is another protocol for doing the same thing. Technical issues aside, it gets my vote because they didn't decide to call it RSS 3. Or RSS 10.
Re:I would consider... (Score:2)
If you don't like something about a protocol, is the correct thing to
Re:I would consider... (Score:2, Funny)
That's because there was already an RSS 2!
Re:I would consider... (Score:3, Informative)
The trouble with RSS (short answer) is that there are at least three different versions of it invented by different people.
Three? Try nine [diveintomark.org].
As far as I know there was an RSS 0.7, then someone else invented a new protocol and called it RSS 1, then the original person invented RSS and called it version 2
No. The short version is that somebody at Netscape invented 0.9something based on RDF. The public release (another 0.9something) was rushed for my.netscape.com and wasn't based on RDF. Then Netsca
Re:I would consider... (Score:3, Interesting)
The w3 refactored HTML 4.01 into XHTML 1.0 using XML instead of SGML. This is similar to the RDF to standard XML change in RSS. Then, the w3 modularized XHTML 1.0 Strict into XHTML 1.1, similar to the back and forth
Re:I would consider... (Score:3, Informative)
Well, these are are XML syndication formats. In other words, they move headlines and article summaries from server to user in machine-parseable format.
There's RSS, which is the reigning de facto standard, but it also is regrettably very, very liberally specified, and even less frequently heeded. Everyone's extending it to their own heart's content more or less competently. There are lots of different variations. Not easy to implement, not easy to learn.
Atom is an attempt to make a real standard-like sta
Hmm... (Score:4, Funny)
Re:Hmm... (Score:2)
whoa nelly (Score:4, Interesting)
Re:whoa nelly (Score:5, Insightful)
Re:whoa nelly (Score:2)
Re:whoa nelly (Score:2, Interesting)
This is the point: Atom is just a fork. RSS is a real concept. Forks come and go, a concept stands.
Re:whoa nelly (Score:2)
Re:whoa nelly (Score:2)
Parent Makes No Sense (Score:5, Informative)
The parent post really doesn't make any sense at all.
Re:whoa nelly (Score:2)
There are at least some out there that would say the article is heavily [docuverse.com] biased [sourcelabs.com]. Not that these responses aren't.
Me? I like RSS 2.0. It's simple (for what is does), and extensible (for most of what it doesn't). To each their own.
Re:whoa nelly (Score:2)
I'm sure it could be argued OGG Vorbis completely demolishes everything that MP3 is/was/used to be also, but does it matter? Like MP3, RSS has already won the mindshare war. Those three letters are already stuck in the minds of bloggers as the very definition of How To Syndicate Content.
Re:whoa nelly (Score:2)
"Bag of bytes" probably would have been more fair/accurate, at least. It is plaintext, after all.
Once again (Score:5, Insightful)
That said, one nice thing about this format war is that there doesn't have to be a loser. It's fairly easy to handle multiple formats in software (note the number of redundant music formats), unlike hardware which is usually impossible. If the process of reading RSS tags or Atom tags is made transparent to the user, who cares who wins?
Re:Once again (Score:3, Insightful)
Re:Once again (Score:2)
Whether or not IE supports a standard has a big bearing on uptake. Look how much more widespread jpeg is to png.
Re:Once again (Score:4, Informative)
Re:Once again (Score:2)
Re:Once again (Score:2)
Re:Once again (Score:2, Informative)
In any case, the majority of sites I visit still use GIFs (1987) for generic elements, like the rounded end on separators and story icons here.
AFAIK, PNG was never aimed at replacing JPEG... its main aim was to provide a better, Compuserve-free GIF alternative.
Re:Once again (Score:2, Informative)
Re:Once again (Score:2)
In any case, GIF is still the most common generic site image format on the sites I visit so I do not quite see this alledged favourism in action. Maybe there is a study somewhere with actual online image format statistics that would say otherwise.
And with GIF's liberation (or even throughout the Unisys/Compuserve episode), most site designers/maintainers simply applied the good old "
Re:Once again (Score:3, Informative)
No, LZW was a major motivator for creating PNG [wikipedia.org], not a mark against it. PNG is LZW free. Also it isn't limited to 256 colors like GIF.
AFAIK, PNG was never aimed at replacing JPEG... its main aim was to provide a better, Compuserve-free GIF alternative.
You're right about that though, if not for the right reasons. PNG wasn't really designed to have anything to do with JPEG, they mostl
Re:Once again (Score:2)
Looks like you did not notice the past tense in "its main aim was to provide a better, Compuserve-free GIF alternative"... back when PNG first came along, this _was_ one of the reasons, even if it no longer is _now_.
Re:Once again (Score:2)
I did indeed notice it. That would be why my first sentence after your quote was, "You're right about this though". I added the "for the wrong reasons" because "Compuserve-free" is not entirely accurate. Unisys was the patent holder on LZW, not CompuServe. CS licensed it from Unisys to make it available for their users in the GIF89 format, which is why it became associated with CompuServe but they weren't technically the "bad guys' here. CS didn't control L
Re:Once again (Score:2, Insightful)
That's a completely back asswards way of looking at it. Website opperators are forced to cater to broken IE implementations not because they are attracted to its features, but because that's what 80% of their visitors are using. And no, if you're a commercial website you can't just say "Screw 'em if they're not smart enough to use Firefox."
So back to the original point, if no one is using Atom, why would website operators publish in Atom? Though I do agree with the point that's been made that it's easy
Re:Once again (Score:2)
Nope, consumers (Score:2)
You are right about that to the point that the web site owners decide what format to use...
The consumers will use what the webmasters use.
Now that is mistaken. The consumers will use what the consumers use. I know that sounds redundant, but consider - Safari already has built in RSS support. IE will have built in RSS support. So how many consumers will actually use Ato
Exactly (Score:2)
Actually, I never researched the differences, so every time I had a choice between Atom and RSS feeds from the same source, I always chose RSS, because I thought Atom was an older style, and also thought that if I ever switched to another reader, it'd be easier to move my feeds if they were all RSS.
Re:Once again (Score:2)
Please tell me you didn't really mean to imply that technical sophistication is achieved by making pretty widgets.
Re:Once again (Score:2)
Please tell me you didn't really mean to imply that all technical sophistication has nothing to do with user functionality and ergonomics
Re:Once again (Score:2)
Please tell me you didn't really mean to imply that all technical sophistication has nothing to do with user functionality and ergonomics ;) .
Certainly not. :-)
But then (at least to my mind), "pretty widgets" doesn't imply user functionality and ergonomics, either.
I think we agree: a product with great technical sophistication can be killed by a bad user interface (which is also technical to some extent), but lack of effective marketing to bring the product to peoples' attention can make both irre
The crucial distinction (Score:2)
They've probably been itching for another good format war to take sides on.
Re:Once again (Score:2)
Re:Once again (Score:2)
How true...I never run into problems trying to get CSS1 and CSS2 to work properly across IE/Safari/Firefox/Konqueror/etc. Granted, some of them implement the standard improperly (*cough...IE..*), but this is what happens when multiple standards exist for the same purpose. I for one don't like re-creating my work for RSS 0.7/1.0/Atom/whatever...that's 3x the work I have to do. And then we'll get RSS 10.0...
Re:Once again (Score:2)
That's right - if they do the same thing noone cares.
I suspect somebody clever will come up with a killer app that will require a feature that either one or the other has that we're not noticing right now, and then noone will remember the other format. As it should be.
format war? (Score:2, Insightful)
I mean there are still 60% who still use that incompatible Browser because they believe that it is the internet and the Modem is a special powercord.
It's not pretty folks (Score:3, Funny)
Smack!
Kapow!
At least put your hands in front of your face.
Whack!
Bam!
Get up off the mat, RSS!!!
Get up!!
I can't watch anymore...
Atom's More Than A Syndication Format (Score:5, Informative)
What's been (all but) finalized is the syndication format (and rules for extending it). This allows the working group to firm up the details of the publishing API, which, for my money, is the real payoff with Atom.
A pretty good overview of the history of RSS and the motivations behind Atom is here [computer.org].
Which one is growing? (Score:4, Insightful)
Besides industry support, my only question would be "which one is growing?" Which of these formats is expected to get a new version number sometime soon?
If you ask me, that is why Microsoft is talking about adding "extensions" to RSS -- by growing and adapting the standard, it gets more bells and whistles, more application support, and more momentum in the development community.
Oracle: More Complicated Pricing Model Needed? [whattofix.com]
Sadly.. (Score:2, Funny)
Cache (Score:3, Informative)
RSS 2.0 vs. Atom vs. RSS 1.0 (Score:5, Insightful)
AFAIK the format war between RSS 2.0 and RSS 1.0 hasn't even ended yet. In spite of the version numbering, RSS 2.0 is more of a .95 than a 2.0 since it's an incremental improvement over .94. It doesn't really add any capabilities to RSS 1.0 (both can support enclosures). The only real difference is that RSS 1.0 is based on RDF while 2.0 isn't; this supposedly makes 2.0 simpler, but potentially less capable.
It's a pity that all the RSS folks couldn't simply hash together a common standard rather than wasting time on competing standards. Is 2.0 really that much simpler than 1.0? Is 1.0 really that much more capable than 2.0? Does Atom really add much to the mix? It seems that it ought to be possible to find a middle ground.
What's Wrong With RSS 1.0 (Score:2)
RSS 1.0 is infinitely extensible because it can be combined with other RDF schemas. In order to extend RSS 9.x, the standard must be extended. This allows its expansion to be controlled, which seems more managable, but as time goes on, features get duct-taped to it in ugly ways.
Because of RSS 1.0's extensibility, its syntax is less human-friendly. This was an
Re:RSS 2.0 vs. Atom vs. RSS 1.0 (Score:2)
Without getting too much into the politics of the syndication world, the reason is that no-one wants to touch RSS 1.0 with a ten-foot pole (even without the bitterness and fallout fro
One thing (Score:5, Interesting)
RSS 2.0 Is Like Perl (Score:2)
RSS 1.0 is slightly more complex but a gajillion times more elegant. It has actual standards for metadata [resource.org].
Re:One thing (Score:2)
Preach it, brother!
I've got an open source aggregator (<plug mode="shameless">Feed for Mac OS X [keeto.net]</plug>) and it seems most of the 'bug fixes' I have to do are directly related to some fools home-grown interpretation of how to deliver content.
Effectively, RSS (the concept, not the format) is in the 'tag soup' phase that the web was in seven years ago. While I expect this will all settle down as the concept (and value) of standardization is realized by content publishes and CMS vendors, it cu
GUID (Score:4, Interesting)
But because an Atom feed must include a guid element, the client has a way of uniquely identifying an item. This means that when you subscribe to an atom feed, you're not going to see duplicate articles the way you do with RSS when the RSS feed doesn't include a guid or any unique identifier (which is legal) and the client has to make one up by hashing the content.
I wrote a bit about this here [stevex.org].
Re:GUID (Score:2)
as long as rss doesn't require you to at least include blank versions of standardized tags we will have the same problems that html has. lots of people out there writing bad code that don't work well for the diversity of readers.
False dichotomy (Score:2)
For those who don't know, RSS 0.9x was basically Dave Winer's personal plaything. When the standards community put together an RSS 1.0 standard, he took his most recent 0.9x 'standard' and renamed it RSS 2.0 to make it look more up-to-date.
Why not take RSS 1.0 and fix the few problems it has?
What Problems? (Score:2)
Sure, RSS 1.0 takes more work to understand up front, but once you get RDF isn't it just another schema? And these days, now that blog software has automatic feeds and there are aggregators available on every platform, how many humans actually need to read it?
Re:What Problems? (Score:2)
We can go on and on... (Score:2)
Newster is aggregatates news from many websites that publish them in RSS. Once the news bits are in the database it uses the ATOM API to post it to the blog. And then it republishes it in ATOM (because its a blogger service). So what we have here is a website that p
No e-mail obfuscation? (Score:2)
As someone who's implemented them both (Score:4, Informative)
Atom wins hands-down. Things are actually well specified [atompub.org] .
I can just walk through the atom specification, implementing it as I go, and not have any questions about what is required, what type of content can be present in any one element, I don't have to look up five even less well-specified different modules just to get the basics of the feed together (and thus also don't have to worry about namespaces), what elements and attributes mean (actually, I spent a minor five minutes agonizing over what I should put in the term atribute of the category element, given that the label attribute contains the human readable version, before realizing that I was completely free in this, as the "scheme" os up to myself, and deciding to mirror how categories are named in the url on the website (which I found to be consistent with various other already existing atom 1.0 feeds [intertwingly.net] that I checked)), or... well, basically any kind of question that you need to think about as you implement a new and previously unknown specification.
RSS on the other hand (any of the 9 incompatible versions)... *shudders* Those specifications don't tell me anything. I copy/paste from other feeds and heavily use the feedvalidator [feedvalidator.org], but... *shakes his head*
Once all feedreaders have been updated to support Atom 1.0 completely, I'll go and pull the plug on the remaining RSS feeds, and good riddance too!
RSS has terribly crappy version control (Score:2)
1) It was written by Mark Pilgrim, one of the major minds behind creating the specification for Atom.
2) Mark's a personal friend of mine, and I personally think he makes sense.
The point of the article is, however, that RSS is terribly broken and fragmented, versions aren't compatible with each other, and it's just a plain mess. Look further on his site and you'll see articles as to not only why he helped c
Which RSS format is this? (Score:2)
Semantics (Score:2)
So while RSS is stuck with regular HTML (escaped markup, whoa!) and images in its contents, Atom can already embed other XML namespaces like XHTML, SVG, MathML, FOAF, Dublin Core...
I think the comparison is similar to the HTML/XHTML one: though right now they can give the same results, in the (not so distant I hope) future Atom/XHTML will become the languages of choice.
Not a lot of people use XHTML+SVG yet, but with Opera supporting it
Podcasting (Score:2, Informative)
It's funny how this writeup doesn't even mention enclosures, despite the hundreds of thousands of people downloading content this way. The only place it comes up is in the chart at the end, which makes some side reference to <link rel="enclosure"> in Atom, which is
Re:Podcasting (Score:2)
Atom has thought about rich media far more than RSS2.0. For example, one of the problems of podcasting is that popular podcasts require stacks of bandwidth. One solution is to offer a bit torrent link. RSS2.0 only allows one enclosure per item, so you can't offer both a straight download and a torrent.
In Atom its st
Re:Podcasting (Score:2)
I just don't get it. Then again, i don't get a lot of recent computer trends... i'm turning 25, and already feel old.
Folks, please support Atom (Score:2)
With that in mind, please support Atom in your future projects. Atom really is a better user experience for end users, and it's better specified and easier to work with as a developer.
The RSS folks are great, and they've put in a ton of hard work, but the Atom spec is Just Better right now, and offers at lot more bang for the developmental buck, not to mention it handles feed aggregations much better.
IE, Firefox/Sage and Safa
Error in the first paragraph? (Score:2)
2005/07/13: RSS 2.0 is widely deployed and Atom 1.0 not at all.
Er... blogger.com (Google's blog service) uses Atom. I think that might count as having been deployed, just maybe...
Buzzword regurgitation (Score:2)
Multicast/Unicast push protocol (Score:2)
Apparently, much bandwidth is wasted just because people can't get themselves out of the only-OSI-level-7+HTTP corset.
Re:Firefox support? (Score:3, Informative)
Re:Firefox support? (Score:3, Informative)
Re:pwned (Score:3, Informative)
Unmolested version [intertwingly.net] - get it while it lasts
copy and paste from google cache (Score:2)
I just copied the one from google cache [72.14.207.104] back into the wiki - we'll see how long it takes before that asshole takes it down again.
Re:pwned (Score:2, Funny)
Grow up
Re:We use it! (Score:2)
Re:We use it! (Score:5, Interesting)
Re:We use it! (Score:2)
Re:We use it! (Score:2)
"They block the transparent proxy"
The reason for this is because about the only thing you can't forge is your apparent, from the Slashdot server's perspective, WAN IP address. Your real WAN or LAN IP is passed in an easy to manipulate X_FORWARDED_FOR or HTTP_VIA HTTP header (both non-standard HTTP/1.1).
Of course, If you add a fake IP address to this header then a legitimate user-agent or proxy should still append you're remote IP. Although, I don
Re:As If I Cared (Score:4, Interesting)
Re:Where's the comparison? (Score:5, Informative)
RSS2.0 had a problem last year where Reuters suffered a public embarrassment adopting the format. They followed the specification correctly, and it resulted in silent data loss - their stock identifiers were in angled brackets and got treated as an HTML tag by news aggregators.
It wasn't rocket science, but this simple thing turned out to be impossible to do with RSS2.0 - it was tried many times. After the funky feed debacle, the community realised that a separate format independent of RSS2.0 was the only way to fix the underlying problem.
The proponents of RSS2.0 tried to fix the silent data loss, and ended up breaking backwards compatibility with RSS0.92 - something they weren't prepared to do before Atom.
Re:What is this stuff *for* anyway? (Score:2)
Re:What is this stuff *for* anyway? (Score:4, Interesting)
I'm not talking about just Dilbert comics or other entertainment outlets. Imagine notification of software updates. Email is lousy for this sort of thing when you get hundreds of emails per day. It's not searchable and it sits in your own account. Another benefit of RSS is control over the lists. You ever get an email from someone you know that didn't really come from someone you know, yet had a nice virus payload attached? This doesn't do that. Any info that comes from the RSS channel is something YOU have subscribed to and unsubscribing is dead easy.
Further, with an RSS Reader I use called Feed On Feeds [minutillo.com], you can access its mySQL backend from any other software to do what you want with the information streams. There are many other readers that use this same philosophy. If you MUST have mailing lists, well, then mail out from there; not all of these sites have mailing lists and this would make a great way to present it in that format. You can reblog select posts, or a channel combining a number of other channels.
Re:Who cares? (Score:2)
That doesn't mean it will take over from RSS