Question.. why RSS and not Atom (Standard)?

[Laibeus Lord]

Hi,

Just one simple question, why choose RSS over the Standards "Atom
(1.0)"? I'm full support of the group, except though when it comes to
RSS ;)

Thanks.

[Chris Saad]

Great question Laibeus... here is the answer...

If you notice all the standards are put into context/application. For
each context/application we have chosen the most popular/simple
standard to achieve the desired result. For simple syndication of
content RSS is the clear winner in terms of mindshare and simplicity.

Atom, however, may still be useful for another context/application -
for example there is talk about using it as part of the WRFS solution
(treating the web as a big relational file system).

But we are happy to be proven wrong - lobby for it in the discussion
and see what happens :)

[Zef Hemel]

I'm an Atom guy myself, but mostly because of other technologies built
on top of it (AtomPub), here's a nice comparison of the two:
http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared

Zef

--
Zef Hemel
E-Mail: z...@zefhemel.com
Phone: (+31) (0)6 156 19 280
Web: http://www.zefhemel.com

[Chris Saad]

Started an FAQ for questions like this
http://groups.google.com/group/dataportability-public/web/overview-faq

On Jan 3, 11:37 pm, "Zef Hemel" <zefhe...@gmail.com> wrote:
> I'm an Atom guy myself, but mostly because of other technologies built
> on top of it (AtomPub), here's a nice comparison of the two:http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared
>
> Zef
>

[Laibeus Lord]

Hi,

Thanks for the reply :D

It's okay, just curious as to why choose RSS over Atom. I was
already thinking the reason was 'popularity'. Although I still
strongly support for Atom as the Syndication platform/tech over RSS
for various reasons we all are aware of already ;) But other than
those reasons, I have nothing else. The way I see it, the only
strength left for RSS is it's popularity which is of course the
obvious choice if we will aim dataportability among all those various
web services. Telling them to use another is really hard.

Anyway. :D But if there's a chance for Atom as the main 'front'
while RSS is secondary choice (ie backwards-compatibility) :p Dunno,
I think I'm just bias towards standards, future-wise. It's really
hard to choose when popularity comes into consideration, if we choose
the recent one, whether its a standard or not, that calls for a mega
extra effort and risks.

Best Regards

^_^

~ Supporter from the Philippines :)

[Simon Willison]

On Jan 4, 2:32 am, Chris Saad <chris.s...@gmail.com> wrote:
> If you notice all the standards are put into context/application. For
> each context/application we have chosen the most popular/simple
> standard to achieve the desired result. For simple syndication of

> contentRSSis the clear winner in terms of mindshare and simplicity.

That was certainly the case a few years ago, but is it really still
true today? I don't know of any modern feed readers (online or
offline) that don't support Atom 1.0, and the same is true for
blogging systems - they all output Atom. Sure, more people have heard
of RSS - but I imagine many people are actually using Atom even though
they call it "RSS".

For me, the core argument in RSS v.s. Atom is that you can't reliably
include HTML meta-characters (less than, greater than or ampersand) in
the title element of an RSS entry due to an ambiguity in the
specification. Has this been fixed now? If not, surely Atom is the
only logical choice.

[anders conbere]

In my experience writing aggregation services atom also comes out on
top by their clear stance on guids (all items have unique guids in
atom). This is opposed to RSS where you have to guess if the item is
the same based on url or guid or title, none of which are required and
all of which might change.

> >
>

[Joaquin Salvachua]

Hello,

Well from my point of view is hard to sell that an standarization
group we dont use the ietf standard for it.
You should have a very good point and reason for doing this.

Just an academical view.

Joaquín Salvachúa

[Julian Bond]

Joaquin Salvachua <jsalv...@gmail.com> Thu, 14 Feb 2008 18:30:28

>Well from my point of view is hard to sell that an standarization
>group we dont use the ietf standard for it.
> You should have a very good point and reason for doing this.

That's one factor. The "De Facto" standard with the biggest
implementation in the market is another.

Which makes it hard to ignore either RSS *or* Atom.

--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
Tax Not Included

[Navarr Barnier]

Then why don't we use both? In fact, I've seen multiple RSS feeds and
examples of RSS feeds that contain atom properties in them using XML
Namespaces. Entwining the two.

---
Navarr Barnier
http://tech.gtaero.net/
http://www.gtaero.net/foaf.rdf

[Julian Bond]

Navarr Barnier <nav...@gmail.com> Sat, 16 Feb 2008 11:56:58

>Then why don't we use both? In fact, I've seen multiple RSS feeds and
>examples of RSS feeds that contain atom properties in them using XML
>Namespaces. Entwining the two.

I think that's the point really. We're going to hit several places where
there's not an obvious single winner in a standards space. RSS-Atom is
relatively easy since parsers typically support both. It's no great
hardship to just support both.

Exporting a profile is perhaps harder because there's FOAF, VCard,
Outlook CSV, LDIF, OpenID AX and perhaps others.

Then there's Identity where OpenID is relatively young and there are
others either more established or equally worthy.

[Mike Pearson]

Perhaps the Dataportability Policy group can help with this...

---

STANDARDS LIFECYCLE

Part of the discussion can be tied to the concept of a standards
lifecycle.
From http://www.e.govt.nz/standards/e-gif/e-gif-v-3-2/standards/chapter2.html

Standards go through the following lifecycle:-
* Future Consideration - emerging; keep an eye on it
* Under Development - playing with it
* Recommended - being used, being adopted
* Adopted - in use now, most common standard
* Deprecated - on its way out, transition off

---

TRANSITION PROCESS

In this example, RSS / ATOM, you have an older standard with a large
install base, and a new standard.

Such transitions take many years to work their way through, think
SSL / TLS or IPv4 / IPv6.

But should we be saying to people, if buying / specifying a new
system, pick RSS ?

Perhaps we need some decision criteria to help make these
recommendations.


---

STANDARDS DECISION CRITERIA

As a starter, here are some questions to ask, to help make
recommendations


- DRIVING FORCE?
Does the standard have sponsorship / endorsement by
- - - Internet bodies e.g. IETF / W3C / OASIS
or
- - - Vendors e.g. Google, Microsoft
or
- - - Interested volunteers e.g. me, you

- EVOLVING or FROZEN?
Does the standard have
- - - a change request process
- - - history of changes in reaction to new Internet technologies /
needs
- - - resources
- - - proof of the above working

SUPPORT?
Are there well defined support mechanisms to look after the standard
- - - Governance e.g. ISO / IETF / OASIS
- - - Guidance e.g. Principles / Policies / FAQs
- - - Infrastructure e.g. bulletin board, website, discussion area
- - - proof of the above working

ADOPTION?
Is the standard adopted or likely to be adopted
- - - In products
- - - In vendor announcements
- - - In the media
- - - In the zeitgeist


If we apply RSS / ATOM against such criteria, what recommendations
would we make?

[bear]

That's just the problem with RSS - *which* standard:

This was taken from http://www.w3schools.com/rss/rss_history.asp :

* 1997 - Dave Winer develops scriptingNews. RSS was born.
* 1999 - Netscape develops RSS 0.90 (which supported
scriptingNews). This was simply XML with an RDF Header.
* 1999 - Dave Winer at UserLand develops scriptingNews 2.0b1 (This
included Netscape's RSS 0.90 features)
* 1999 - Netscape develops RSS 0.91. In this version they removed
the RDF header, but included most features from scriptingNews 2.0b1.
* 1999 - UserLand gets rid of scriptingNews and uses only RSS 0.91
* Netscape stops their RSS development
* 2000 - UserLand releases the official RSS 0.91 specification
* 2000 - A group lead by Rael Dornfest at O'Reilly develops RSS
1.0. This format uses RDF and namespaces. This version is often
confused as being a new version of 0.91, but this is a completely new
format with no ties to RSS 0.91
* 2000 - Dave Winer at UserLand develops RSS 0.92
* 2002 - Dave Winer develops RSS 2.0 after leaving Userland
* 2003 - The official RSS 2.0 specification is released

Now if you want to drill down into some of the technical issues of why
not RSS you can run into a couple speed bumps from the start - date
formats, UID's that are not unique, html/no-html, namespaces (can you,
must you, which) and so on.

But with Atom you get one single IETF standard that is now just as
widely used as what collectively is called RSS now.

I've had to deal with as a consumer, and also a producer, both RSS and
Atom and I much prefer Atom now.

thanks,
bear


On Jan 3, 8:38 am, Chris Saad <chris.s...@gmail.com> wrote:
> Started an FAQ for questions like thishttp://groups.google.com/group/dataportability-public/web/overview-faq

[Navarr Barnier]

This is a very valid point. Although RSS is used a lot, different versions
are used of it all over the internet.

For a quick Example:
RSS 1.0: http://rss.slashdot.org/Slashdot/slashdot
RSS 2.0: http://feeds.css3.info/css3

Atom on the other hand, although not used at often, has a very strict
standard, is often coupled in RSS, is supported by many readers and
collectively called "RSS", and on a number of sites, is offered as an
alternative alongside of RSS.

To continue moving DataPortability in the right direction, I believe that it
would be best to work with Atom instead of RSS.

-Navarr

-----Original Message-----
From: dataportabi...@googlegroups.com
[mailto:dataportabi...@googlegroups.com] On Behalf Of bear
Sent: Sunday, February 17, 2008 1:34 AM
To: DataPortability.Public.General
Subject: [DataPortability-Public] Re: Question.. why RSS and not Atom
(Standard)?

[Julian Bond]

bear <bea...@gmail.com> Sat, 16 Feb 2008 23:33:30

>But with Atom you get one single IETF standard that is now just as
>widely used as what collectively is called RSS now.
>
>I've had to deal with as a consumer, and also a producer, both RSS and
>Atom and I much prefer Atom now.

So it looks to me like DP should be recommending
- Produce Atom // Because it's a better standard
- Consume Atom/RSS //Because you can't ignore the installed base

The one problem I've had with Atom (actually with RSS as well) is
support for the extensions and less rarely used options. Jaiku produce
an Atom feed that is quite like the Twitter feeds except that they put
the author into an <author> tag. So far so good, except that they don't
put the author text into the title or description. So the parsing tool
has to know about how Jaiku is using the standard to assemble something
that is readable by a human. And tools or ways of working that were
built for Twitter produce dumb output from Jaiku feeds.

This exposes a problem with complex or very extendable formats. The
receiving developer needs to know about all the variations and allow for
them. Both in the standard and in common usage. Consuming FOAF suffers
from this as your app may know about and expect the vcard: tags and have
no clue what to do with bio: tags.

Which is to say that DP can do a great service by documenting and
promoting best practice use of standards as well as which standard to
use.

[Mark Shiu]

If different version affects our decision, should we be more flexible with it?
Maybe define functionality instead of technology, and allow companies to choose from existing/recommended technologies?

Mark Shiu

[Douglas Sims]

The ability to share data between systems (data portability with lowercase letters) requires that the holder of the data makes it available in a specified, published, and open format, not any specific format.

I hope that this group will not require a specific protocol or format in order to consider a holder of data as practicing good portability.  I think requiring specific protocols or formats would lead to this group being seen as advocates for that specific protocol rather than the general idea that holders of data should make it available to others at the direction of the owners of the data.

[Tim Bray]

On Feb 16, 11:56 pm, Julian Bond <julian_b...@voidstar.com> wrote:

> So it looks to me like DP should be recommending
> - Produce Atom // Because it's a better standard
> - Consume Atom/RSS //Because you can't ignore the installed base

This seems like the most sensible course. The consuming part is easy
because all the libraries out there handle at least the popular RSS
variants. If you decide to produce RSS, you have to figure out which
RSS you mean, there are lots of them: cheap & cheerful 0.9*, uglified
1.0 with added Semantic Web goodness, or the popular RSS 2.0 family.
Yes, that's plural, there is Dave Winer's original RSS 2.0 at
http://cyber.law.harvard.edu/rss/rss.html and the competing 2.0.10
produced by the "RSS Advisory Board" at http://www.rssboard.org/rss-specification
- given the personalities involved, these forks will not be unforking
any time soon.

Atom does have some technical advantages for data producers too. -Tim

[DeWitt Clinton]

Tim's exactly right, perhaps even understating the case.

Atom is the better choice if the consumer of the feed is expected to parse and interpret the content.   Atom explicitly identifies content types, which is important if you want to syndicate anything more structured than plain text with escaped markup.  Given that this discussion is about data portability, not text/html portability, I imagine that this is a hard requirement.

I wrote about lossy and opaque content a while back -- please forgive the link, it is easier than restating the background:

 http://blog.unto.net/work/on-rss-and-atom/

Nothing against RSS at all (one of the greatest innovations of our time), but tightening up the protocol so that it could be properly used for data syndication was one of the reasons that Atom was created in the first place, and one of the primary reasons companies like Google use Atom over RSS for their data apis.  And as others have pointed out, everything at least reads Atom these days, and more sophisticated content/data syndication may well require it.

Not sure the group needs to make a recommendation though.  I figure that this would just evolve organically.

-DeWitt

[Laibeus Lord]

I never thought this will grow this much, but reading all, seems to me
there favor is with Atom as the choice for "Feeds".

I agree that Atom is collectively included with "RSS", because people
use the 'name' "RSS" and not the 'term' "Feed". But personally, I
believe there are more Atom 1.0 users out there than all of the RSS
flavors combined, the 'name' RSS is just the popular word and not the
'term' "Feed".

I use Atom for all my blogs and sites where there are feeds, I dropped
all RSS support because I am in favor of using the official standards,
with having standards and supporting it, it guarantees future
compatibility, as we say, "Future-proof". Atom have a clear road
ahead while RSS development has stopped years ago. And during my
personal testing, I found Atom to be giving what I want and most of
what I want to be syndicated than the fragmented RSS (one feature will
work with RSS1 but not on RSS2, you get the idea).

I agree with the link provided above: "on-rss-and-atom".

Anyway, this is just my personal opinion on the matter. If it still
can be changed, then I am strongly in favor of Atom 1.0.

Best Regards

[Joaquin Salvachua]

Then something like Must implement Atom and May implement other RSS
feeds mechanism????

Joaquín.