OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] best practice for providing newsfeeds ?

[ Lists Home | Date Index | Thread Index ]
  • To: <bob@wyman.us>,"Michael Champion" <mc@xegesis.org>,"XML DEV" <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] best practice for providing newsfeeds ?
  • From: "Joshua Allen" <joshuaa@microsoft.com>
  • Date: Mon, 2 Feb 2004 14:12:09 -0800
  • Thread-index: AcPp17/93a/qRo/1RFCN8BFr2WGzOQAAE5UA
  • Thread-topic: [xml-dev] best practice for providing newsfeeds ?


> 	1. Virtually every RSS reader actually reads at least three
> different flavors of RSS and often as many as seven. All of the these

So now it will be at least three and as many as *eight*?

> various formats are underdefined in one way or another. Agreement on
> what their elements mean is only approximated through a process of
> voluminous and expensive back-channel communications. (Note: The RDF

How does adding yet another incompatible format help this problem?  And
for a user who is using RSS 2.0 and their aggregator works just fine,
why would they care that some techies are arguing about semantics?
Sounds like the best approach is to just standardize on RSS 2.0.

> original creation. (Atom defines both "created" date and "issued"
> date. This allows the distinction to be made.)

Great, a techie feature.  My grandmother certainly didn't ask for that
one.  You are saying it is a *feature* of a syndication format that you
require feed authors to keep track of even more metadata?  Half the
people out there still haven't even figured out how to set the pubDate
properly.

> 	3. There are very few commonly shared conventions for
> encapsulating HTML content in RSS feeds. Sometimes you get a CDATA,
> sometimes the tag soup is just inserted into an element, sometimes, it
> comes with enclosing <html> tags, sometimes, it doesn't. Sometimes, it
> is split up into two elements (a <description> and a <content>

OK, so lets make yet another convention to confuse people even more?
Getting people to follow a common convention is not solved by inventing
specs, it's solved by getting people to change behavior.  The same
people you would need to convince to do it the right way in Atom are the
people you could just as easily convince to do it the right way in RSS.

> 	On my site, we constantly process data from over 1 million RSS
> feeds (Yes, we've grown a bit in the last week...)and what we see is a
> cesspool of badly formed data. It is "just" barely clean enough to do

And you are certainly not the only site who does so.  Technorati,
Popdex, Moreover, Syndic8, all process massive amounts of feeds.  You
aren't going to stop supporting RSS 2.0 any time soon, and neither are
they, so Atom is only going to make your job more difficult.  And in the
meantime, the fact that you *can* process these millions of feeds is
proof that RSS is working.

Sorry, all I am hearing is FUD, griping about lack of pet personal
features, arrogance about purist architecture notions, and wishful
thinking about how yet-another-format will make everything better.  I
haven't seen a single good argument that would make a CIO decide to take
the cost and risk of switching from RSS to Atom when/if it ever is
finalized.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS