Loading ...
Sorry, an error occurred while loading the content.

On RSS, Community, Extensibility, and more...

Expand Messages
  • Rael Dornfest
    Howdy, This seems an apropos spot to wander in with some thoughts I ve been having along these lines. These thoughts are my own, mind you, and should not be
    Message 1 of 1 , May 29, 2001

      This seems an apropos spot to wander in with some thoughts I've been having
      along these lines. These thoughts are my own, mind you, and should not be
      construed as representing the opinions of any group/faction/flavour.

      I've cc'd the [Syndication] list since these thoughts tie together
      conversation[1] occuring on both lists. This is not a short note, but I do
      ask that you bear with me as I believe it covers some important ground.

      James Shaw wrote[2]:
      > Here's a question that's undoubtedly controversial - and I'm only
      > half serious in asking - presuming that aggregators ignore unknown
      > elements, I *could* just add some new elements to a 0.92 file for use
      > by my "closed loop" of publishers and directories. Losing the
      > rdf:about's would be a big saving, and publishers would still get the
      > added value of having a channel to submit to RSS aggregators.

      Controversial, yes. Out of left field, certainly not!

      This practice, in fact, was what first prodded me to dive into the extension
      of RSS in the first place. I'd observed a couple of behaviours resulting
      from RSS's lack of extensibility:

      a) Overloading
      Folks were (and still are) overloading RSS 0.91 elements to the point
      where one is almost forced into the abominable situation of "screen-
      scraping" their favourite RSS feeds to either get at this valuable
      'extra' data or remove the clutter. A simple example is Moreover's
      RSS 0.91 feed, throwing ource and Date into the <description>

      <title>Sequenom, Gemini Genomics in merger pact</title>
      AP via New Jersey Online May 29 2001 12:29PM ET

      And they get far worse than that

      b) Ad Hoc Extension
      While inherently a harmless activity given that the majority of
      RSS readers, aggregators, and other tools ignore what they don't
      understand (read: optional elements/attributes), this does doesn't
      exactly do wonders for interop. One person might create an ad hoc
      <source> element containing the URL of the original source of the
      story. Another might use <source> for the proper name of the news
      source and <source_url> for their URL. What's an RSS reader to do?

      In the early days, Meerkat actually had filters for some of these
      as I ran across them, mapping <keywords> in one feed and <topic>
      in another to its own <subject> field. Ick!

      Dave Cantrell wrote[6]:
      > While I can't speak for the RSS-DEV group in any way, I personally
      > don't see what the problem would be with using 0.9x and adding your
      > own extensions via namespaces. I mean, isn't that what the namespaces
      > thing is all about? Is there some deep dark magic I'm missing that
      > would prevent this, or would otherwise break existing usage?

      My initial strawman for the progression of RSS back in May/June, 2000[3]
      proposed 3 simple requirements that might go quite some way to affording
      RSS extensibility without more than replacing one already required text
      attribute with a URL and allowing for optional extensions, ignoreable by
      those who don't understand them.

      * Extensibility without need of iterative modifications [and
      centralized agreement thereon] to an RSS core specification.

      * Backward compatibility with existing RSS (currently 0.91) easily
      accomplished with the the simple requirement that core RSS parsers,
      modules, and libraries ignore what they weren't built to understand.

      * An effort toward interop with a set of community-built modules
      providing the functionality required most of the time by folks.
      Anything else can be done on an ad hoc basis.

      I built a simple modularization demonstration[4] to aid visualization.

      The gist is of it is simply changing:

      <?xml version="1.0"?>
      <rss version="0.92">


      <?xml version="1.0"?>
      <rss xmlns="http://backend.userland.com/rss092/">

      That's it! While retaining the simplicity of RSS 0.9x, you've opened the
      door for folks to extend it (whether working as a group or individually) to
      meet their applications' needs. Current users happy with simply doing
      headline syndication have only one tiny change to make (and there are ways
      around even requiring that). Advanced users can modularly extend to their
      hearts' content. And everyone else "in the middle" can start simple and
      have their RSS evolve with them.

      For example, borrowing a page from Slashcode:

      <?xml version="1.0"?>

      <rss xmlns="http://backend.userland.com/rss092/"

      <title>Javascript Banner Code Error in Header Block</title>
      <description>a description</description>


      (This example is borrowed from Slashcode's current RSS 1.0 module)

      Slash have here borrowed some common elements from the Dublin Core (15
      common ways to describe a thingy): creator, subject, date. And then they've
      created their own slash module with home-grown elements: section, comments,

      And all it took was a couple more declarations at the top, associating the
      shorthand dc with Dublin Core and slash with the Slashcode module. So, what
      slash:comments really says is "there are 7 comments (as defined by
      Slashcode) on this item." And dc:subject says "the (dublin core defined)
      subject of this item is 'slash'." No muss, no fuss. No complex syntax.
      And no need of RDF.

      And those tools not understanding the particular modules at hand or even
      namespaces themselves simply sees:

      <title>Javascript Banner Code Error in Header Block</title>
      <description>a description</description>

      > I extended RSS with a custom namespace to allow us to embed extra
      > information (such as time and location of the event, etc).
      > This IMO "stretches" the original RSS intent a bit, but it works (a key
      > argument from the standpoint of the 0.9x crowd).

      RSS _is_ being stretched, whether by individual users or those coming
      together for an updated version. Making provision for this is a good thing.
      Ignoring it or attempting to pack the core of RSS with all the bits and bobs
      everyone wants dooms us to a centrally governed, bloated core and gets in
      the way of just getting our jobs done.

      Now it seems you two and folks like you are caught in the middle here.
      Extensibility is key to your using RSS in your application, but you'd rather
      not have to buy into the whole kit, kaboodle, and RDF model of today's RSS
      1.0. I understand that completely and very much want to find a middle
      ground here on which to build. Contrary to what you might have heard
      regarding my motives, "it just works" has always been key to me.

      On the RDF front...

      Yes, the syntax is a little less than georgous for the uninitiated. Yes,
      the syntactic sugar added to 0.9 to make it fully RDF compliant can get in
      the way of a good read. But the RDF model is powerful, sound, and, in
      concert with RSS, can bear some intriguing recombinations and applications.
      I'm more than thrilled RSS 1.0 took this path and look forward to its
      contined evolution.

      On to the [Syndication] bit... (I promise this note will end shortly, really

      Dave Winer wrote:
      > 1. Having two RSSes is killing RSS.

      We agree and disagree here. On the one hand, yes RSS's current split
      personality can be confusing and offputting to beginners and seasoned
      users alike. I also believe that perhaps another huge factor is that
      neither format captures the needs and levels of understanding of the
      majority of users, across the board.

      On the other hand, RSS and reformulations thereof is cropping up
      _everywhere_, from Ximian's Red Carpet to Slashcode to Take23.org's RSS 1.0
      based portal, to desktop aggregators and desktop integration. It already
      had great breadth, and for this I credit your evangelism completely; now it
      is gaining some depth and finding itself novel uses.

      And, if you'll permit the Tevia-ism, on the third hand, the single thing
      that's wearing on RSS is the partisanship. Scarcely a proposal can be made
      or element questioned without an eruption. Sure, compartmentalization of
      discussion helps a bit, but do we really need the confusion of 3 (or more)
      lists, the exclusion of particular folk from participating in discussion,
      and constant lobbying on all sides... at the expense of understanding and
      the uninitiated?

      Overall, though, I think we agree.

      > 2. None of the confusion from April of last year has abated, imho it's
      > much more confusing today than it was back then.

      Yes, it is much more confusing today, but a little less so than a few months
      ago. On the subject of last April, I actually don't understand why you'd
      call that time confusing. We were all talking on [Syndication] about
      possible directions for RSS. I gave you a ring and we talked at length on
      the subject. I followed your advice and formalised my thoughts, initially
      with a strawman, followed by a visual demonstration and spec(ish). This all
      culminated in the RSS 1.0 proposal.

      Yes, there were some confusing bits, but I don't think we really want to get
      into those here.

      All in all, one thing has become remarkably clear. We need to find a middle
      road. Not you and I, but we as a community of users. There's been so much
      good work done on all sides. Instead of repeating efforts, we should find
      those cross-links and build some bridges.

      > 3. Since you and I are the two people who could do the most to abate the >
      confusion, I suggest that you roll up your sleeves, as I am willing to
      > do, and let's solve the problem.

      I've always been willing to roll up my sleeves and work on resolution. As
      for solving the problem, that will take much input from all sides.

      > I made a proposal in a subsequent
      > message. It would be helpful if you gave it some thought and responded
      > publicly, preferably on this list.

      Let's take a peek[7], shall we...

      > 1. I will stand down as the defacto leader of the simple approach to RSS,
      > I'll just be another user of RSS, making proposals, and looking for
      > input or agreement with others.

      I have to agree with Morbus here; I just don't see this happening. The only
      way to assure this seems to be:

      1. The establishment of some sort of governance as we've done on
      RSS-DEV[8]. Please don't dismiss these out of hand because they
      come from RSS-DEV; it's a decent system based upon good thoughts.

      2. Equal access to discussion, dissent, and moderation. Throwing folks
      out of Vogon cargo holds (off lists, that is) or preventing them
      from speaking is a no-no in the world of working together.

      3. Really attempting to work together, not in words alone.

      Dave, you simply must be in any discussion of this type. To pretend it
      weren't so would simply be silly.

      > 2. I'll pass the baton to someone who isn't so convenient a target for
      > your personal issues. I would recommend Jeff Barr, he's got longevity in
      > RSS, a product, and a lot of experience. I don't know if he has the time.

      Rather than naming an heir apparent, I think a simple process of nomination
      and voting would be a fantastic way to start.

      > 3. Along with this, you will also stand down, by renaming the RDF and
      > namespaces format to something other than RSS,

      A note on names. You have, in the past, in addition to requesting a name
      change, nixed the letters RSS. I'm afraid I don't think that will fly very
      far. Despite your claims that RSS 1.0 is not RSS, its users and proponents
      certainly feel it is. I've already spoken with you of various alternatives,
      including xRSS, eRSS, RSSx, and RDFSS. Please state your position once and
      for all in public on this point.

      As I've said at various points to you, Dave, this is not my decision to
      make. I am a member and chair of a working group and do not consider that a
      position from which to unilaterally make such decisions or coerce others
      into changing their minds.

      I do, however, invite you to pop on in to RSS-DEV and call for a poll or put
      forth a proposal to consider a name-change (let's leave the exact name up in
      the air for now) which I'll be more than willing to second. If you're
      really serious about your proposal, take a leap of faith and simply ask the
      folks who can answer.


      Again, these are just some thoughts buzzing about in my brain -- have been
      for a while. I'm not promoting one flavour in particular, suggesting a
      backtrack, or proposing a merge. I am answering some questions, asking a
      few more, and hoping for some honest-to-goodness constructive discussion and
      possibly a few bridges built along the way.

      Please follow up to more neutral ground, syndication@egroups.com, on the
      non-RSS 1.0-specific bits.


      [1] http://groups.yahoo.com/group/syndication/message/1658
      [2] http://groups.yahoo.com/group/rss-dev/message/1966
      [3] http://weblogs.oreillynet.com/rss/
      [4] http://www.oreillynet.com/~rael/data/xml/rss/modular/demo/
      [5] http://slashcode.org/slashcode.rss
      [6] http://groups.yahoo.com/group/rss-dev/message/1967
      [7] http://groups.yahoo.com/group/syndication/message/1651

      Rael Dornfest

      "My greatest strength is... common sense.
      I'm really a standard brand--like Campbell's
      tomato soup or Baker's chocolate."
      --Katharine Hepburn
    Your message has been successfully submitted and would be delivered to recipients shortly.