Re: [syndication] RSS 0.91 - skips & optional stuff

[Rael Dornfest <rael@oreilly.com>]

On Mon, 12 Jun 2000, Dan Lyke wrote:

> On Mon, 12 Jun 2000, Dave Winer wrote:
> > I don't understand. Do you have an example? Dave
> 
> Dave Winer was referring to David Galbraith's comment that:
> > > The problem with aggregating using RSS at the moment is that if
> > > you pull together a list of related items from different sources
> > >  then the aggregator appears to be the source.
...
> If Moreover is grabbing a couple of different RSS feeds and further
> integrating them, perhaps in some custom feed that puts the Flutterby and
> Scripting News RSS files into yet another file that it feeds to the end
> customer, there's no audit trail for how those records got into that final
> file (Most of us bloggers do it in our HTML versions with "Via xyz" sort
> of link).

That's exactly the problem for aggregators, especially when you get into
the aggregation of aggregations arena.

> I think the answer is that RSS really isn't a format for publishing
> weblogs in, that in being essentially a flat-file database with a little
> meta information at the top rather than a markup, it's really meant to be
> a "I have these files available" rather than a "here's the cool stuff you
> should see" format.

Actually, as a vehicle for weblogs, RSS does a fine job.  The Manila News
Item / RSS implementation is top-notch -- I've been using it for all of my
bloggings since it became available.

> So it seems that the thing for me to do most inline with the philosophy of
> RSS (and I've only had enough feedback from those who use my RSS files to
> know that they're being used, not how) would be to cut any links out of it
> that aren't to content that's either hosted on Flutterby or by me.

But aggregators still have this problem to solve.  It could be solved, as
suggested by Dave G., with the addition of a couple of tags.  My fear with
this reasoning is that as tags are added to the RSS spec over time to
take into account everyone's needs, it *might* become rather big and
messy.  There seem to be three main directions in which we might go to
solve these sorts of problems:

  * Carefully craft an RSS that fulfills most needs, most of the time.
  * Be ok with multiple forks specifically tailored to the needs of the
    application/implementation.
  * Modularize RSS, with a simple/clean base spec overlaid with 
    well-designed modules solving specific classes of problems.

Rael

------------------------------------------------------------------
  Rael Dornfest                  rael@oreilly.com
  Developer & Maven,             http://www.oreillynet.com
  The O'Reilly Network           http://www.oreillynet.com/~rael