Re: How is Atom superior to RSS?
On 5/22/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > > ...your effort to create a concise list is very much appreciated Here's one for RSS1: the Dublin Core "module" required to approach Atom's core capabilities is extremely poorly defined. It doesn't even commit to a string literal for fields like dc:creator. This makes it challenging to fill a text field in an end-user application, even one that actually processes RSS1 with an RDF parser(!). https://bugzilla.mozilla.org/show_bug.cgi?id=287793 Robert Sayre
Re: How is Atom superior to RSS?
Bob Wyman wrote: This has been an experiment... I've got lots of thoughts on why Atom is an improvement over RSS but I am constantly amazed that people are able to continue making the claim that Atom offers little that RSS doesn't already support. Certainly, Winer and the Microsoft crowd make that claim regularly. I've often wondered why people don't see the really important differences between these two. To a certain extent, the answer comes in the replies I've received to my posting. i.e. Not even those most familiar with Atom can present a decent list of clear advantages -- even though they undoubtedly know them. Yes, we all know the advantages of requiring unique atom:id values, writing less ambiguous documentation, etc. However, I wonder why advances like the following don't get more recognition (note: this is not a complete list.) 1. Explicit support for xml:lang rather than the silly tag of RSS V2.0. While your effort to create a concise list is very much appreciated, I would recommend avoiding terms like "silly". 2. Explicit support, in the core, for digital signatures and encryption. 3. Atom Entry documents. Thus, support for the protocol as well as for push delivery of Atom feeds via Atom over XMPP and other such protocols. (i.e. Atom is designed to enable a push future rather than only working in the legacy pull-only world of RSS) 4. Atom:source elements which provide robust support, in the core, for attribution on entries that have been copied from one feed to another and for preservation of important feed metadata in copied entries. Atom's source element makes it a superior format for delivering search results, for constructing feeds which aggregate entries from multiple sources, and for push applications. 5. Support for XML content types rather than being limited to RSS's HTML content type. It isn't even clear what RSS's content type is. Particularly for title. Even for RSS 1.0. 6. Explicit support for "remote content". We all worked hard in getting these new capabilities and others like them into Atom and properly defined. Why aren't these things given more "press" and attention? They are significant improvements over RSS that will have profound impact on our ability to build better applications for our users. Add atom:updated solves exactly this problem: http://www.25hoursaday.com/weblog/CommentView.aspx?guid=4c8d83e9-bc7e-432d-b5b2-07965bd959ad Add multiple "enclosures". http://weblog.burningbird.net/archives/2005/05/03/feeds-fixes/ Add relative URIs: http://intertwingly.net/slides/2003/xmlconf/34.html Add clear distinction between summary and content: http://www.imc.org/atom-syntax/mail-archive/msg15208.html http://www.imc.org/atom-syntax/mail-archive/msg15266.html - Sam Ruby
RE: How is Atom superior to RSS?
This has been an experiment... I've got lots of thoughts on why Atom is an improvement over RSS but I am constantly amazed that people are able to continue making the claim that Atom offers little that RSS doesn't already support. Certainly, Winer and the Microsoft crowd make that claim regularly. I've often wondered why people don't see the really important differences between these two. To a certain extent, the answer comes in the replies I've received to my posting. i.e. Not even those most familiar with Atom can present a decent list of clear advantages -- even though they undoubtedly know them. Yes, we all know the advantages of requiring unique atom:id values, writing less ambiguous documentation, etc. However, I wonder why advances like the following don't get more recognition (note: this is not a complete list.) 1. Explicit support for xml:lang rather than the silly tag of RSS V2.0. 2. Explicit support, in the core, for digital signatures and encryption. 3. Atom Entry documents. Thus, support for the protocol as well as for push delivery of Atom feeds via Atom over XMPP and other such protocols. (i.e. Atom is designed to enable a push future rather than only working in the legacy pull-only world of RSS) 4. Atom:source elements which provide robust support, in the core, for attribution on entries that have been copied from one feed to another and for preservation of important feed metadata in copied entries. Atom's source element makes it a superior format for delivering search results, for constructing feeds which aggregate entries from multiple sources, and for push applications. 5. Support for XML content types rather than being limited to RSS's HTML content type. 6. Explicit support for "remote content". We all worked hard in getting these new capabilities and others like them into Atom and properly defined. Why aren't these things given more "press" and attention? They are significant improvements over RSS that will have profound impact on our ability to build better applications for our users. bob wyman
Re: How is Atom superior to RSS?
Bob Wyman wrote: I’ll be making a presentation on Tuesday which will include a slide on how Atom improves on RSS. If you have any thoughts on this subject, I would appreciate hearing them… Much of the following is still relevant: http://intertwingly.net/slides/2003/xmlconf/ I'm not certain what topic your presentation is supposed to cover, but hopefully there is room to mention the protocol. - Sam Ruby
Re: How is Atom superior to RSS?
* Bob Wyman <[EMAIL PROTECTED]> [2005-05-22 01:52-0400] > I'll be making a presentation on Tuesday which will include a slide on how > Atom improves on RSS. If you have any thoughts on this subject, I would > appreciate hearing them. Which version of RSS? the RDF and non-RDF strands have pretty different characteristics... The main new interesting thing for me is the protocol aspect. Re format extensibility, Atom's a step back from RSS 1.0, but a step forward from RSS 2.0. Digital signature stuff is exciting. Dan
Re: How is Atom superior to RSS?
Off the top of my head * Less ambiguous * Broader solution space * Defined extensibility model * Defined encryption and digital signature support * Support for additional content types and scenarios (e.g. linked content as opposed to embedded) Will be interested in seeing the final list you come up with. A. Pagaltzis wrote: * Bob Wyman <[EMAIL PROTECTED]> [2005-05-22 08:05]: I'll be making a presentation on Tuesday which will include a slide on how Atom improves on RSS. If you have any thoughts on this subject, I would appreciate hearing them. I think the main attractions are pretty clear: • Thoroughly specified • Well-defined content model • Entry IDs • Mandatory timestamps There are also many other valuable features (I like the explicit summary vs content distinction, f.ex) which wouldn’t sell the format on their own. Regards,
Re: How is Atom superior to RSS?
* Bob Wyman <[EMAIL PROTECTED]> [2005-05-22 08:05]: > I'll be making a presentation on Tuesday which will include a > slide on how Atom improves on RSS. If you have any thoughts on > this subject, I would appreciate hearing them. I think the main attractions are pretty clear: • Thoroughly specified • Well-defined content model • Entry IDs • Mandatory timestamps There are also many other valuable features (I like the explicit summary vs content distinction, f.ex) which wouldn’t sell the format on their own. Regards, -- Aristotle
How is Atom superior to RSS?
I’ll be making a presentation on Tuesday which will include a slide on how Atom improves on RSS. If you have any thoughts on this subject, I would appreciate hearing them… bob wyman