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

RSS-Classic, RSS 1.0 and a historical debt

Expand Messages
  • Dan Brickley
    I m really suprised to be having this discussion over again. This message is rather long, and contains a number of excerpts from ancient RSS history that I was
    Message 1 of 27 , Nov 7, 2000
    • 0 Attachment
      I'm really suprised to be having this discussion over again.

      This message is rather long, and contains a number of excerpts from
      ancient RSS history that I was hoping not to need to wave around. But
      this RSS naming debate has gone on too long, and it's time to settle it.


      Contrary to what you might hear, the RSS 1.0 proposal did not come from
      a bunch of outsiders who swooped in and grabbed the prestigious acronym
      'RSS'. RSS 1.0 as proposed is solidly grounded in the original RSS
      vision, which itself had a long heritage going back to MCF (an RDF
      precursor) and related specs (CDF etc). This can be seen for
      example from Guha's longstanding involvement, and Dan Libby's account of
      the Netscape RSS work and endorsement of the 1.0 proposal.

      The bigger picture that Netscape's RSS effort presented was one that
      connected RSS syndication (my.netscape portals etc) to channel and
      sitemap functionality in their next-generation Web browser technology
      (the XML/RDF-based Mozilla, see http://www.mozilla.org/rdf/doc/),
      as well as to open Web directory services, ie. the
      Dublin Core Open Directory RDF dumps (available at http://dmoz.org/rdf.html).
      This was a pretty good thing to aim at, and with RSS 1.0 I believe we're
      in with a chance of delivering it.

      I for one am fed up with the repeated accusation that we (to put
      it bluntly) stole RSS from Dave Winer. I've been through that debate once[1]
      on the FoRK list, and it wasn't at all pleasant.

      The continuing fuss about the name for the NS/RDF-based RSS 1.0
      document is doing nobody any good. Dave very graciously conceded the
      point back in September[2]; I fail to see why we're still burning
      bandwidth on this topic many weeks later. Hence this historically
      oriented message.

      We proposed RSS 1.0 in the light of several years experience with RSS
      and related technologies. The 1.0 proposal does its best to play well
      with related specifications (eg. Dublin Core), to remain close to the
      0.9, yet to learn from the problems we've encountered with deploying and
      extending earlier RSS specs.

      If there is interest in continuing to evolve and polish RSS-based specs
      in the "RDF and namespaces, no thanks" tradition ([3]), that's just
      fine. RSS-Classic is a perfectly good name for this effort. We can
      explain how to map between RSS 1.0 and RSS-Classic formats, and explain
      the different approaches to extensibility and format evolution adopted
      by each approach.

      But I'm thoroughly tired of being accussed (on list and off) of our
      having 'stolen' RSS. Those of us working on RSS 1.0 have an obligation
      to make sure RSS-Classic deployers are left in the picture, and that
      (bi-directional) conversion tools and suchlike are made available. The
      sooner we put the naming issue behind us, the sooner we can get to work
      on a complete picture of the RSS landscape.


      I believe we have more than adequate historical justification for
      calling the 'new' stuff RSS. To defend this observation requires
      pointing to a bunch of historical baggage that I've previously avoided
      publicising. I thought we'd had this debate and the result was 'RSS 1.0'
      and 'RSS-Classic'. It appears not.



      So, let's get this over with. Some historical observations.

      scriptingNews (the immediate source of the additional elements added
      into the last version of RSS before Netscape dropped the ball) was quite
      plainly derrived from Microsoft's Channel Definition Format (CDF).

      The RSS timeline at http://backend.userland.com/rss091 neglects to
      mention this. Dave, when questioned on this point [4], declined to name
      any technical innovation in scriptingNews that wasn't already in the
      well known CDF spec that predated scriptingNews _and_ RSS. Nothing in
      scriptingNews (sometimes claimed as the original RSS spec in all but
      name) was interestingly new. scriptingNews was a clone of CDF. I
      believe this to be an uncontroversial observation rather than an
      accusation of any bad doing.

      But don't take my word for it. See
      http://ilrt.org/discovery/2000/08/rss/forked/forked.txt for samples of
      scriptingNews, RSS 0.91 and the original CDF spec, which was proposed
      even before XML was finished. Spot the difference.

      CDF wasn't the only spec that pre-dated XML. Quite some time before CDF
      and scriptingNews, there were hundreds of grassroots MCF channels out
      there. A directory of URLs still survives (thought the site's up
      and down) at http://www.xspace.net/hotsauce/sites.html (page last
      updated Nov 1997, if their HTTP headers are to be believed.). MCF was
      Meta Content Format, basically Guha's work at Apple (before he moved to
      Netscape, and before MCF fed into the RDF design at W3C and the
      RSS designs at Netscape). MCF attempted to do two things: (1) provide a
      simple text format that content creators could use to expose
      machine-readable news channels and sitemaps (2) back
      this up with a rich and extensible information model, so it had some
      hope of scaling to the Web. Way back then, we saw significant
      grassroots adopting of MCF. The list of (mostly broken, sadly) links at
      http://www.xspace.net/hotsauce/sites.html shows that MCF was a very
      practical, deployable option back then.

      The RSS timeline at http://backend.userland.com/rss091 neglects to
      mention this work, and RSS's relationship to it. MCF channels / sitemaps
      directly fed into the original RSS design. On the contrary, the claims
      in http://my.userland.com/stories/storyReader$11 ignore both CDF and MCF:

      [[
      For many people <scriptingNews> format will be new, but it's
      actually the oldest syndication format on the
      web. It was first described and deployed publicly in December 1997...
      ]]

      This claim (and implied claim w.r.t. RSS) is misleading. Whether true or
      not depends on one's notion of 'syndication'. Since the CDF example I
      link to above is couched in terms of news articles, I find it a hard
      claim to believe.

      The creation of scriptingNews was directly influenced by both CDF and
      MCF specs. I believe the ommissions from the Scripting News
      RSS timeline have fueled the (very frustrating) debate about renaming
      "RSS 1.0" and "RSS-Classic". Intentionally or otherwise, implementors
      new to the scene may be unaware of the history. This can give people the
      impression that scriptingNews was the source of many of the ideas found
      in the various flavours of RSS. I don't believe that to be the case.


      The Web tends to remember this sort of thing. Here are some of things
      documents I found (using Google and Google cache[5]) while checking up
      on the history of all
      this...


      January 1997, Dave Winer was proposing MCF-based additions to the Apple
      'Finder'. http://www.its.unimelb.edu.au/hma/pub/macscrpt/d112/0088.html

      Same month, an article in MacWeek,
      http://www.access.ch/power/infoservices/MacWeek/MacWeek270197.html#Index22
      discussed Netscape's acquisition of Netsape's HotSauce/MCF technology
      (along with Guha).

      [[
      The company said it will incorporate Meta Content Format (MCF) into a
      future version of Constellation, Netscape's
      enterprise-oriented Internet-on-the-desktop technology first announced
      in November (see 11.25.96, Page 91).
      ]]


      A few months later, DaveNet featured some observations on 'Push' (then a
      fashionable buzzword), http://davenet.userland.com/1997/04/25/NoTheoriesNeeded

      [[
      Fri, Apr 25, 1997; by Dave Winer.

      Microsoft and Pointcast, who aligned in March on a standard
      way of describing dynamic web content called Channel Definition Format,
      or CDF, seem to be going their own ways now. The docs for CDF are
      scanty, we haven't received verification from Microsoft that we're
      correctly supporting it, I suspect that's not possible because CDF is
      still being specified.

      And even if CDF were complete, I have trouble seeing the
      substance. I've identified three dynamic pages on the DaveNet site,
      described in a CDF file. Can any software read this file and do
      something interesting with it?
      [...]
      ]]

      Incidentally, a copy of an early CDF spec is available at
      http://www.scripting.com/midas/cdf.html

      Investigating http://www.scripting.com/midas/ we learn that

      [[
      UserLand is working on both sides of the Meta
      Content Format spec -- in content tools and in browsers.
      ]]

      which leads us to http://www.scripting.com/midas/mcf.html
      (dated Wednesday, August 27, 1997.). Dave writes...

      [[
      MCF and UserLand

      UserLand is working on both sides of the Meta Content Format spec
      -- in content tools and in browsers.

      I had a few hours on Christmas morning to do some experimenting and
      planning. It looks like there's an opportunity for us to add to the MCF
      standard. It also looks like it's happening, so it's time to jump on the
      bandwagon and start digging...

      ]]


      So I have to say I fell off my chair when I read this. After weeks of
      being accussed on bandwagon jumping, theft, lies and worse, this was an
      interesting find. Dave jumped the MCF bandwagon rather than vice versa.

      There's a nice MCF representation of Dave's site at
      http://www.scripting.com/frontier/siteMap.mcf incidentally.

      [[
      ;This MCF File was generated by Userland Frontier 4.2 Mac
      -1/20/97; 10:30:40 AM
      ]]

      An example entry looks like this:


      unit: "http://www.scripting.com/frontier/admin/credits.html"
      name: "Frontier: Credits Page"
      authorIndividual: #"dwiner@..."
      authorOrganization: #"UserLand Software"
      firstPublicationDate: "12/29/96"
      lastRevisionDate: "12/29/96"
      size: "8323"
      parent: #"www.scripting.com/frontier/admin/"

      Sound familiar? It ought to...

      Returning to the detail of the MCF and Userland page, we learn something
      of Userland's MCF implementation and plans, including some downloadable
      code (ftp://ftp.scripting.com/userland/snippets/utilities.buildMCF.sit.hqx)
      that integrates MCF export capabilities into Frontier. Go Dave! :-)


      We learn more about this work from the transcripts of 'DaveNet live',
      still in '97. These are still online at
      http://167.216.203.60/Events/ny97/Transcripts/53.html and include some
      observations on "Push" technologies of the time, including MCF and
      CDF...

      Excerpts:
      [[
      DaveNet Live
      Dave Winer, UserLand Software, moderator

      [...]

      Mr. Winer:
      CDF, we've already implemented CDF support. CDF is an awful lot like
      MCF, which was a proposal that Apple had out
      there, which basically describes pieces of a Web site. So you can say,
      we actually implemented it, and my Web site is a
      CGF channel now. So, I found three pages on my Web site that will change
      on a periodic basis. All the rest of the pages
      pretty much survive. I'll point to those pages from these dial-up
      pages. It's such an incredibly immature idea - that I
      mean the Microsoft people I sent them an e-mail, to Ben,who is the lead
      developer on Internet Explorer and to Don,
      who is in charge of their Macintosh stuff, and said, "Hey, CDF?" And
      that e-mail must have gone everywhere in
      Microsoft, and I got back incredibly enthusiastic response. "Wow! We
      can't believe it." Of course, at that point we had
      completed our application of CDF. So I think a part of their disbelief
      was that they didn't think it was possible for
      anybody to do it.

      And so we very quickly got it together, finished it, and then sent them
      back for pointers, and said, "Would you please
      take a look at this, and tell us if we've actually got it right?" And I
      never heard anything back from them after that point.
      So, my guess is that they don't know what this stuff is used for. I
      don't know what it's used for, but we support it,
      okay?

      Audience: [inaudible]

      Mr. Winer: That's out of date. Our MCF file is not something we build on
      a regular basis.

      Audience: [inaudible]

      Mr. Winer: Absolutely. The way we have it we have the CDF stuff hooked
      in so that every time the site gets built that
      page gets regenerated. So it's not hard to do that, but MCF seems to be
      dead. It was only being kept alive, I think,
      because Apple was promoting it. It was in that magic list of things that
      they're no longer doing.

      Audience: [inaudible]

      Mr. Winer: Perhaps, and maybe MCF will happen anyway. I would add it to
      the list of things we support, but I think it's
      so much like CDF that it's the same thing fundamentally. It's a site
      description thing, okay?

      Pointcast was one of the sponsors of CDF when they had this big press
      conference down in Los Angeles in Internet
      World. They were on stage with Microsoft saying, "Rah, rah, CDF we
      support it all the way." I had a talk with Chris
      Hassett, CEO of Pointcast, and he said the same thing. So we called up
      the product manager, and asked him that we
      would like to make sure our stuff works with Pointcast. He told us he
      would get back to us. [...]

      ]]


      All this speaks for itself, but lets join the dots here.

      On the basis of these various observations, we have two
      traditions, both rooted in Guha's MCF work.

      MCF > CDF > scriptingNews > RSS 0.91 > RSS-Classic
      //
      MCF > XML-MCF > RSS 0.90 > RSS 1.0


      Although much of the above is in DW's own words, a different perspective
      can be found at http://davenet.userland.com/1999/06/16/aFaceOffWithNetscape
      tells of a face-off with Netscape, and the (familar sounding) threat of
      a forking of the specs, with the new arrivals (Netscape) failing to
      inter-operate with the long-established scriptingNews:

      [[
      Wed, Jun 16, 1999; by Dave Winer.

      As I've written previously, when Netscape came out with their
      web syndication format in March, it was too
      good an opportunity to pass on. We had been working
      in this area for over a year, on two of three sides of the
      problem, as a content developer, publishing an XML-syndicated
      channel; and as a tools vendor, providing software to
      organizations that develop web news channels.
      [...]
      Enter Netscape. With some fanfare, in March they introduced
      RSS, and quickly there were a hundred compatible channels.
      [...]

      Outcome

      I hope Netscape will now work with us so this world doesn't
      have to fragment. I think we were generous by holding back on
      our format to see if we could work with Netscape. We published
      our format publicly in 1997, long before Netscape entered this
      area. We informed many Netscape people about it.

      Unfortunately most, if not all of them no longer work at
      Netscape. To the current management at Netscape, whoever
      they may be, let's work together.
      ]]




      To stress my point once more. The RSS 1.0 proposal did not appear from
      out of nowhere, but is routed in 5 years work in this area. The
      RSS 1.0 proposers did not swoop in from nowhere to steal the 'RSS'
      acronym. Whichever way you trace RSS history (via scriptingNews /
      CDF) or directly back through Netscape's acquisition of Apple's
      MCF, it isn't hard to figure out who jumped whose bandwagon. I don't
      make these points to embarrass Dave (I don't believe that's even
      possible), but to put a stop to a pointless debate.

      "RSS 1.0" and "RSS-Classic" work just fine. Let's get back to the real
      work...

      Dan



      [1] http://xent.ics.uci.edu/FoRK-archive/sept00/0211.html

      [2] http://xent.ics.uci.edu/FoRK-archive/sept00/0268.html
      and http://xent.ics.uci.edu/FoRK-archive/sept00/0271.html
      [[
      From: Dave Winer (dave@...)
      Date: Wed Sep 13 2000 - 15:23:49 PDT

      Here's the deal. Call it RSS 1.0. You win.

      ]]

      [3] http://xent.ics.uci.edu/FoRK-archive/aug00/0609.html
      [4] http://xent.ics.uci.edu/FoRK-archive/sept00/0215.html
      http://xent.ics.uci.edu/FoRK-archive/sept00/0224.html

      [5] prefix URLs with
      http://www.google.com/search?q=cache: if the older links break...
    • Seth Russell
      ... Well maybe that should tell you there is still a real problem. Look, this thing is past the point of justifications being important. Im sure your
      Message 2 of 27 , Nov 7, 2000
      • 0 Attachment
        Dan Brickley wrote:

        > I'm really suprised to be having this discussion over again.

        Well maybe that should tell you there is still a real problem. Look, this thing is
        past the point of justifications being important. Im sure your position is
        justified. Rather now this is only a political matter. It relates to what feels
        right and what feels wrong to a real people out here. Now, personally I don't have
        any vested interest (ego) in either the WG group or in Dave's group. But it doesn't
        feel right to me. I don't understand the divisive stubbornness that keeps the WG
        from just changing the name. But I do see the political magic that would happen if
        we just changed it. Especially since XRSS is the better name anyway and actually
        names this thing politically correct.

        Heal the Rift
        Start anew
        Change the name!

        Seth Russell
      • Rael Dornfest
        Howdy, ... I ll say that its advised if you want to be 0.9 backward-compatible. Any objections? Rael ... Rael Dornfest rael@oreilly.com
        Message 3 of 27 , Nov 9, 2000
        • 0 Attachment
          Howdy,

          On Mon, 6 Nov 2000, Eric van der Vlist wrote:

          > Aaron Swartz wrote:
          > >
          > > Eric van der Vlist <vdv@...> wrote:
          > >
          > > >> Syntax: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
          > > >> xmlns="http://purl.org/rss/1.0/">
          > > >> Requirement: Required exactly as shown, aside from any additional namespace
          > > >> declarations
          > > > Do we really mean so ? [What about other namespace prefixes?]
          > >
          > > For backwards compatibility with 0.9 (which required the use of the rdf
          > > prefix to be compatible with non-namespace-aware parsers) we must force this
          > > prefix.
          >
          > :(
          > Do really need to keep this one ?
          > We've already given up the restriction to "the full ASCII character set,
          > as well as all legal decimal and HTML entities" and I think it's at the
          > same level...

          I'll say that its advised if you want to be 0.9 backward-compatible. Any
          objections?

          Rael

          ------------------------------------------------------------------
          Rael Dornfest rael@...
          Maven, http://www.oreillynet.com/~rael
          The O'Reilly Network http://meerkat.oreillynet.com
          ------------------------------------------------------------------
        • Rael Dornfest
          Howdy, ... So what would you write, then? Suggestions welcome ;-) Rael ... Rael Dornfest rael@oreilly.com Maven,
          Message 4 of 27 , Nov 9, 2000
          • 0 Attachment
            Howdy,

            On Tue, 7 Nov 2000, Leigh Dodds wrote:

            > > That's exactly my point.
            > > I think we should specify in the spec that elements and attributes from
            > > other namespaces can be added everywhere, even in modules elements and
            > > that the tools should just ignore what they don't support.
            >
            > Thats fine by me - so long as its clear that this can take place then
            > we should be OK.
            >
            > My initial quibble was that the models for the core elements are declared
            > in the specification as being: #PCDATA. Reading that at face value means
            > that I shouldn't expect additional elements. If we could change that to
            > reflect the actual intention, then I'm happy.

            So what would you write, then? Suggestions welcome ;-)


            Rael

            ------------------------------------------------------------------
            Rael Dornfest rael@...
            Maven, http://www.oreillynet.com/~rael
            The O'Reilly Network http://meerkat.oreillynet.com
            ------------------------------------------------------------------
          • Rael Dornfest
            Howdy, ... Done (though not yet online). Rael
            Message 5 of 27 , Nov 9, 2000
            • 0 Attachment
              Howdy,

              On Mon, 6 Nov 2000, Eric van der Vlist wrote:

              > 3.3 RDF and parseType Literal
              >
              > > While modules are not required to take full advantage of RSS 1.0's RDF framework,
              > > effort should at least be made to construct modules in a way that doesn't
              > > confuse RDF parsers. To this end, any element containing XML markup (i.e. other
              > > elements) that is not written as RDF should signal RDF parsers that this
              > > markup should not be interpreted, instead maintained as a value using the
              > > parseType="Literal" attribute.
              >
              > As previously discussed, I think we should be more general here and ask
              > modules writers to define vocabularies that are RDF compliant
              > (parseType="Literal" is only one of the criteria) and also to do their
              > best to provide coherent data models for both pure XML and RDF.

              Done (though not yet online).

              Rael
            • Aaron Swartz
              ... I m sorry, but I don t see how we can do this as Eric suggests, and still maintain RDF compatibility. The following example would be incompatible with RDF
              Message 6 of 27 , Nov 9, 2000
              • 0 Attachment
                Rael Dornfest <rael@...> wrote:

                >> My initial quibble was that the models for the core elements are declared
                >> in the specification as being: #PCDATA. Reading that at face value means
                >> that I shouldn't expect additional elements. If we could change that to
                >> reflect the actual intention, then I'm happy.
                > So what would you write, then? Suggestions welcome ;-)

                I'm sorry, but I don't see how we can do this as Eric suggests, and still
                maintain RDF compatibility. The following example would be incompatible with
                RDF (I've tested it with SiRPAC):

                <item rdf:about="http://xml.com/pub/2000/08/09/xslt/xslt.html">
                <title>Processing Inclusions with XSLT</title>
                <link>http://xml.com/pub/2000/08/09/xslt/xslt.html</link>
                <description>
                Processing document inclusions with general <k:word>XML</k:word> tools
                can be problematic. This article proposes a way of preserving inclusion
                information through <k:word>SAX</k:word>-based processing.
                </description>
                </item>

                If we wanted to allow this, I believe it would hopelessly complicate the
                spec. We'd need to use a system such as parseType="literal", which would
                require RDF applications to do both an RDF parsing, and then an XML parsing
                of the results of the RDF parse. I do not think this is in the spirit of our
                RDF support.

                If other modules would like to use parseType="literal" to get this type of
                functionality, that would be fine. However, I do not believe this should be
                part of the core -- RDF parsers should be able to count on the core as a
                reliable source of plain text, rather than marked-up content.

                --
                [ Aaron Swartz | me@... | http://www.aaronsw.com ]
              • Leigh Dodds
                ... change that to ... Content Model: ANY Which is the current thinking I believe. IOW, you can t guarantee what you re going to get in any of those elements
                Message 7 of 27 , Nov 10, 2000
                • 0 Attachment
                  > > My initial quibble was that the models for the core elements
                  > are declared in the specification as being: #PCDATA. Reading that at face
                  > value means that I shouldn't expect additional elements. If we could
                  change that to
                  > reflect the actual intention, then I'm happy.
                  >
                  > So what would you write, then? Suggestions welcome ;-)

                  Content Model: ANY

                  Which is the current thinking I believe.

                  IOW, you can't guarantee what you're going to get in any of those elements
                  if we don't want to enforce the 'no change in content model' rule.

                  L.


                  --
                  Leigh Dodds, Systems Architect | "Pluralitas non est ponenda
                  http://weblogs.userland.com/eclectic | sine necessitate"
                  http://www.xml.com/pub/xmldeviant | -- William of Ockham
                Your message has been successfully submitted and would be delivered to recipients shortly.