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

[Dan Lyke <danlyke@flutterby.com>]

On Mon, 12 Jun 2000, Dave Winer wrote:
> Dan, I want your RSS file to contain pointers to stories you feel are
> relevant, whether or not they are on Flutterby.

Since I'm generally too lazy to change what's already working, my scripts
will likely stay doing exactly that.

I think my message really muddied the waters by bringing up a separate
issue. Sticking to the first one:

> And any affiliate that hooks into our story flow also knows where the
> link came from.

How? If nick a link from you my HTML versions are going to look like:

  <p>Via <a href="http://www.scripting.com/";>Scripting News</a>, here's
  <a href="http://whatever.com";>Some cool article that I first saw on
  Dave's site</a>. Go check it out!</p>

But my RSS feed is going to be:

  <item>
  <title>Scripting News</title>
  <link>http://www.scripting.com</link>
  </item>
  <item>
  <title>Some cool article that I first saw on Dave's site</title>
  <link>http://www.whatever.com/</link>
  </item>

With 'blogs this isn't really an issue (except, see below), the Moreover
guys on the other hand are probably trying to leverage webloggers as
filters, and probably trying to automatically find who the really
influential bloggers are (Since Malcolm Gladstone seems to be in vogue
right now, consider this your gratuitous "Tipping Point" reference) and
I'd also bet that they're occasionally blowing off that Netscape
restriction of 15 entries per RSS file, so in a published stream they want
their users to be able to filter by resource, by number of recommenders,
and similar.


Now comes the transition to the other stuff that muddied the waters:

When I originally saw RSS I thought "Great, an easy way to download a
whole bunch of 'blogs all at once, strip their formatting to make it
readable on my Pilot/Laptop/monochrome terminal/whatever and display it
all on one page so I don't have to wait for my clicks to take.

RSS isn't suited for that. Your Scripting News format, Whump's syndication
format, or even straight HTML is better, because as we've all learned from
playing in this medium for a few years the comments and perspectives are
most of the added value, and often one topic demands multiple linked
articles.

In fact as I worked with people trying to syndicate Flutterby we
eventually converged on http://www.flutterby.com/short.html and in the
meantime the tools for parsing more byzantine HTML have gotten *much*
better.

*** WARNING: This is where Dan takes someone saying "it'd be fun ***
*** to build a potato cannon" and proceeds to ponder a device to ***
*** put a beer can on the moon, which, of course, is too complex ***
*** to actually implement.                                       ***

  Also: It looks like there's actually progress being made here. Don't let
  my ramblings because I had an hour free while I waited for a download to
  happen before I could continue working drag this off into a theoretical
  discussion which leads to lots of mental masturbation but nothing
  getting built. Y'all have followed this list for a while, and many of
  you are implementing much more publicly usable code on this topic than
  I.


All of my content flows through an XML stream before it gets converted to
HTML. The DTD for this started out as roughly a stricter HTML2.0 minus the
appearance stuff and is mutating as I better identify information. For
instance, one of the things I'm playing with is better use of the <cite>
tag, so that I can say: <cite type="book"> which would tell me I can look
up the cited title in my book database when I render to HTML, or even
something like:

   <cite type="movie" name="phantom menace">Fandom Menace</cite>

So that I can then later say "Show me all the records which reference Star
Wars episodes 1 through 9" even when my Star Wars reference was a pun (the
hard part is that I like "fire and forget" tools and this requires
interactive writing tools smart enough to say "He italicized that, let's
see if we can find a lookup and ask for clarification if it appears
ambiguous").

The other reason for this is that often I'm referencing a concept and not
a given link, or the link may move. A "<via>" tag is an obvious extension,
since I'm not referencing a specific article this is also something that
can follow URLs around, eg: Wes Felter's "Hack The Planet" as he went
through the pain of dealing with his line to his apartment and various
ISPs before landing on editthispage.com.

My internal format isn't useful for this sort of syndication because I
still have "<i>" and "<b>" tags in it rather than forcing my writing to
use "<cite>" and "<em>" and the like, but I would like to work towards a
content type that I can use to publish my data and not lose some of the
semantic information that I'm managing to retain internally.

Jorn Barger's solution for this in his various rants against XML was
smarter text parsing, but I believe that that has to be a part of the
authoring environment, so that the writer can do the disambiguation, and
it needs to be interactive, so that rather than figuring out if that
closing punctuation (or whatever) is a part of the URL or of the sentence
the writer can fix potential errors on the front-end.

But if the publication formats and the authoring environments don't get
there first we will be stuck with trying to parse the English. I don't
really think that'll serve anyone.