Subject: How is Atom superior to RSS?

From: "Bob Wyman" <[email-masked]>
Date: Sun, 22 May 2005 01:52:48 -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.

bob wyman

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 22 May 2005 08:50:42 +0200

* Bob Wyman <[email-masked]> [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

---

From: James M Snell <[email-masked]>
Date: Sun, 22 May 2005 00:11:17 -0700

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.

---

From: Dan Brickley <[email-masked]>
Date: Sun, 22 May 2005 09:45:05 -0400

* Bob Wyman <[email-masked]> [2005-05-22 01:52-0400]
> Atom improves on RSS. If you have any thoughts on this subject, I would

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

---

From: Sam Ruby <[email-masked]>
Date: Sun, 22 May 2005 13:29:14 -0400

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

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 22 May 2005 15:21:32 -0400

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 <language/>
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

---

From: Sam Ruby <[email-masked]>
Date: Sun, 22 May 2005 17:23:20 -0400

> 	1. Explicit support for xml:lang rather than the silly <language/>

While your effort to create a concise list is very much appreciated, I 
would recommend avoiding terms like "silly".

> 	5. Support for XML content types rather than being limited to RSS's

It isn't even clear what RSS's content type is.  Particularly for title. 
  Even for RSS 1.0.

> have profound impact on our ability to build better applications for our

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

---

From: Robert Sayre <[email-masked]>
Date: Sun, 22 May 2005 17:39:39 -0400

On 5/22/05, Sam Ruby <[email-masked]> 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