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

RSS-DEV

Expand Messages
  • Rael Dornfest
    Howdy, Welcome to the RSS-DEV mailing list, home of a working group for the further development of RSS ( RDF Site Summary ). Abstract ... RSS ( RDF Site
    Message 1 of 8 , Aug 14, 2000
      Howdy,

      Welcome to the RSS-DEV mailing list, home of a working group for the
      further development of RSS ("RDF Site Summary").

      Abstract
      --------
      RSS ("RDF Site Summary") is a lightweight multipurpose
      extensible metadata description and syndication format. RSS is
      an XML application, conforms to the W3C's RDF Specification
      and is extensible via XML-namespace and/or RDF based modularization.

      Design Goals
      ------------
      The modular extension of existing RSS through XML Namespaces and RDF
      stressing backward compatibility with RSS 0.9 for ease of adoption
      by existing syndicated content producers.

      Documents
      ---------
      RSS 1.0 Specification Proposal
      http://purl.org/rss/1.0/

      RSS 1.0 Modules
      http://purl.org/rss/1.0/modules/

      Discussion
      ----------
      Interested parties, please join the working group at:

      http://www.egroups.com/group/rss-dev

      Regards,

      Rael

      ------------------------------------------------------------------
      Rael Dornfest rael@...
      Maven, http://www.oreillynet.com/~rael
      The O'Reilly Network http://meerkat.oreillynet.com
      ------------------------------------------------------------------
    • Aaron Swartz
      A few questions: How was the spec developed? Was it done through email discussion between the authors? If so, why did you choose this route, instead of a more
      Message 2 of 8 , Aug 14, 2000
        A few questions:

        How was the spec developed? Was it done through email discussion between the
        authors? If so, why did you choose this route, instead of a more public
        method? Would you be open to making the archives of this discussion
        available, so we could see the reasons behind some of the decisions?

        How "final" is the spec? Is it stable enough to begin publishing/aggregating
        in? Do you still expect discussion on it? Will discussion be able to impact
        the final version of the 1.0 spec or will it go into a future version?

        Do you plan to update http://weblogs.oreillynet.com/rss/ which is where
        http://purl.org/rss/ points to?

        Sorry, just sort of taken off guard by the sudden appearance of the spec?

        A few thoughts:

        I think the image element should also be deprecated and perhaps replaced by
        a module that allows per-item images (like Slashdot's "icons").

        Proposed addition to the syndication module: the publish-date of the
        article.

        Possible additions (to fit in somewhere): an author metadata (pointing to an
        email address or a website for the author of the item) and persistent IDs
        for items (so that corrections to an RSS file don't cause aggregators to
        interpret it as a new item, thus duplicating the item).

        Also, if I were to publish comments on articles in RSS, how would I say that
        the comment refers to a specific article. Is this another module? I have a
        feeling this might be supported in RDF, but I'm not sure how.

        In conclusion, thanks to all the authors for their hard work and coming out
        with a really nice spec. I'm glad to see progress in the RSS format and even
        happier to see that RDF is back!

        Thanks for all your hard work,

        --
        Aaron Swartz |"This information is top security.
        <http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
        <http://www.theinfo.org/> | - Marshall McLuhan
      • Rael Dornfest
        Howdy, Aaron. ... I ll take your questions as an opportunity to provide a little background for those just joining us. You probably recall much of the back and
        Message 3 of 8 , Aug 14, 2000
          Howdy, Aaron.

          On Mon, 14 Aug 2000, Aaron Swartz wrote:

          > How was the spec developed? Was it done through email discussion between the
          > authors? If so, why did you choose this route, instead of a more public
          > method? Would you be open to making the archives of this discussion
          > available, so we could see the reasons behind some of the decisions?

          I'll take your questions as an opportunity to provide a little background
          for those just joining us.

          You probably recall much of the back and forth on the Syndication
          mailing list following my RSS Modularization Demonstration[1] and
          subsequent "Spec(ish)"[2]. The debate revolved, for the most part,
          around in-core flat extension of RSS (adding n new elements to 0.91)
          versus relational (using XML Namespace-based modularity)[3].

          My initial "Spec(ish)" and demonstration, while providing a useful
          bit of visualization, were rather crude. On the advice of Dave Winer
          [4][5] and wanting to rethink various assumptions (both my own and
          those of the RSS developers over time), I set about writing up a more
          formal proposal.

          In the midst of a discussion on my proposed Threading module, Eric
          van der Vlist made an astute observation (and one I'd been glancing
          at myself):

          Eric van der Vlist wrote:

          > The functionality is real nice, but shouldn't we consider using RDF ?
          > (I am afraid we might be reinventing RDF statement ;=)

          I wrote:

          "...which brings us back to DO..." I was wondering how long it would
          take. What does the "R" in "RSS" stand for again? ;-)[6]

          He went on to point out that everyone was dancing around RDF, wanting
          some of its flavour and features, but not the RDF name[7]. My argument
          against RDF[8] was simply backward compatibility with RSS 0.91 and the
          possible confusion value of RDF if not done right.

          RSS 0.9 had indeed had a "nod" to RDF -- outer rdf:RDF element -- but
          this had been removed in 0.91. Questioning my assumptions on how hard
          it would be to reintroduce RDF, I experimented with "putting the toothpaste
          back into the tube" if you will. While introducing RDF into RSS 0.91 was
          a simple enough task in itself, there was that backward compatibility
          issue.

          As I bounced ideas off Eric and others, they became interested in the
          puzzle and rolled up their sleeves. We bandied about various ideas before
          I hit upon it: why not simply start with that RDF nod already present in
          RSS 0.9? Surely that would provide a starting point upon which to build.
          With vi, the W3C's handy-dandy SIRPAC-based visualization tool[9] (I
          like pictures), etc, we set about building on 0.9, testing for RDF-compliance
          and backward-compatibility using some RSS tools (XML::RSS, for one). I was
          working upon the assumption that many of the RSS tools and scriptlets folks
          were using to parse RSS simply ignored what they didn't understand -- namely
          attributes, namespace bits and pieces, and even ad-hoc elements providing
          they did not affect the overall structure of the RSS document.

          It didn't take long to realize that only a spoonful or three of syntactic
          sugar would make RSS 0.9 RDF-sound and also provide for XML Namespace-based
          modular extension. We wrote it up, incorporated some of the earlier
          module thoughts and proposals[10], and announced it here, on RSS-DEV
          and other appropriate mailing lists today.

          Quite a treatise that turned into; it certainly is some good organic
          growth -- and interesting, hopefully.

          > How "final" is the spec? Is it stable enough to begin publishing/aggregating
          > in? Do you still expect discussion on it? Will discussion be able to impact
          > the final version of the 1.0 spec or will it go into a future version?

          Proposals are, I believe, the beginning (or at least the middle) of a
          conversation[11], not the end. It is for this reason that we chose to
          start a mailing list-based working group -- open, unmoderated, and
          publically-viewable -- and why we invited members of the RSS, syndication,
          RDF, and various other communities to come take a gander and chat.

          At the same time, I do want to encourage adoption at least alongside
          RSS 0.9, 0.91, ScriptingNews, and other flavours. I've done just that
          with Meerkat[12] and ask folks to start implementing at least the core,
          seeing where their needs are, and suggesting extensions.

          > Do you plan to update http://weblogs.oreillynet.com/rss/ which is where
          > http://purl.org/rss/ points to?

          Heh. I've uploaded all of these files for posterity to RSS-DEV's
          "Defunct" file folder[13]. I've also pointed the /rss/ and /rss/modules/
          PURLs to the current RSS 1.0 Specification and RSS 1.0 Modules documents,
          respectively. The weblogs.oreillynet.com/rss site will be shut down
          shortly (I want to clean up loose ends/links first).

          > Sorry, just sort of taken off guard by the sudden appearance of the spec?
          >
          > A few thoughts:
          >
          > I think the image element should also be deprecated and perhaps replaced by
          > a module that allows per-item images (like Slashdot's "icons").

          Or indeed, multiple possible images of different sizes and/or resolutions,
          perhaps?

          We didn't want to deprecate anything that might affect backward
          compatibility.

          > Proposed addition to the syndication module: the publish-date of the
          > article.
          >
          > Possible additions (to fit in somewhere): an author metadata (pointing to an
          > email address or a website for the author of the item) ...

          Some of this may be found in the Dublin Core elements in the third full
          example in the spec[14].

          > ... and persistent IDs
          > for items (so that corrections to an RSS file don't cause aggregators to
          > interpret it as a new item, thus duplicating the item).

          Good idea. I had something like this in my ultra-old RSSx straw-man.
          It consisted of concatenated URL and date. Dublin Core, I believe,
          can be brought into play here too.

          > Also, if I were to publish comments on articles in RSS, how would I say that
          > the comment refers to a specific article. Is this another module? I have a
          > feeling this might be supported in RDF, but I'm not sure how.

          Heh. This relates to the inchannel RDF resource and position attributes.
          I'll let Dan and/or Gabe jump in here.

          > In conclusion, thanks to all the authors for their hard work and coming out
          > with a really nice spec. I'm glad to see progress in the RSS format and even
          > happier to see that RDF is back!

          Glad you feel that way; and glad you're rolling up your sleeves as usual.

          Rael

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

          [1] http://www.egroups.com/message/syndication/188
          [2] http://www.egroups.com/message/syndication/214
          [3] http://www.xmlhack.com/read.php?item=621
          [4] http://www.egroups.com/message/syndication/202
          [5] http://www.egroups.com/message/syndication/218?&start=189
          [6] http://www.egroups.com/message/syndication/204
          [7] http://www.egroups.com/message/syndication/205
          [8] http://www.egroups.com/message/syndication/207
          [9] http://jigsaw.w3.org:8000/description
          [10] http://weblogs.oreillynet.com/rss/modules
          [11] http://www.egroups.com/message/syndication/206
          [13] http://www.egroups.com/files/rss-dev/Defunct/Modular_RSS_Specish/
          [14] http://www.egroups.com/files/rss-dev/specification.html#s7_1.0w_modules
        • Aaron Swartz
          ... I think both would be useful. ... How does deprecation affect backward compatibility? While I appreciate the work done to make sure 1.0 is backward
          Message 4 of 8 , Aug 15, 2000
            Rael Dornfest <rael@...> wrote:

            > Or indeed, multiple possible images of different sizes and/or resolutions,
            > perhaps?

            I think both would be useful.

            > We didn't want to deprecate anything that might affect backward
            > compatibility.

            How does deprecation affect backward compatibility? While I appreciate the
            work done to make sure 1.0 is backward compatible, I'd hate to see the
            baggage (textinput and image) left over from Netscape hobble the spec as it
            moves forward.

            Textinput and image are very much Netscape-specific, and work best in
            designs that work like My Netscape does. I'd like to see RSS move forward
            and drop these legacy values. However, I do see your reasoning and it makes
            sense to keep image for the time being and add additional functionality
            through modules. It just seems a little odd with some values seemingly
            "blessed" by the spec and others having to be added on with namespaces. Oh
            well.

            >> Possible additions (to fit in somewhere): an author metadata (pointing to an
            >> email address or a website for the author of the item) ...
            > Some of this may be found in the Dublin Core elements in the third full
            > example in the spec[14].

            Oh, good point. I had forgotten about DC.

            >> ... and persistent IDs
            >> for items (so that corrections to an RSS file don't cause aggregators to
            >> interpret it as a new item, thus duplicating the item).
            > Good idea. I had something like this in my ultra-old RSSx straw-man.
            > It consisted of concatenated URL and date. Dublin Core, I believe,
            > can be brought into play here too.

            Yes, the dc:identifier property would work nicely, the question is what to
            put in it. URL and date would work, although it would look a bit odd and
            would quite make sense as a URL. Of course, this goes well with my other
            suggestion:

            > Proposed addition to the syndication module: the publish-date of the article.

            The other question is what is the proper date format. I suggest using RFC
            822 to be consistent with RSS091 values.

            --
            Aaron Swartz |"This information is top security.
            <http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
            <http://www.theinfo.org/> | - Marshall McLuhan
          • Ian Graham
            I ve read the RSS 1.0 spec. As an RDF-aware extrapolation of RSS 0.9x this is quite nice. However, I am looking for something a bit different: namely, a
            Message 5 of 8 , Aug 15, 2000
              I've read the RSS 1.0 spec. As an RDF-aware extrapolation of RSS 0.9x
              this is quite nice. However, I am looking for something a bit different:
              namely, a syndication framework that can contain RSS-style data, but that
              could also contain other sorts of data. In particular I would like to be
              able to distribute event descriptions (conferences, concerts, etc.), the
              full text of some articles, and so on.

              I've been mulling this over for a few weeks, and have some rough thoughts
              on this model and its relationship to RSS. To my mind, this would call
              for a modular language that can describe the following classes of
              information:

              * location data - where the 'resource' can be accessed from
              * metadata describing basic properties of a resource (data type,
              last modified date, who is the author/owner of the 'resource', etc.)
              * metadata describing syndication rules for the resource
              data (when it should be displayed, how it can be redistributed)
              * descriptive metadata describing the content of a
              resource (the language it's in, keywords and category labels,
              etc.)
              * the resource itself.

              Most of this information is defined, in a limited way, in the various RSS
              elements or attributes. However, I suspect that by abstracting these away
              from being tied to the RSS 'channel' model, and by constructing a suitable
              XML framework for generic syndication data, we can make a more extensible
              specification that can encompass RSS 0.9x-style data in addition to other
              forms, and that can also allow for extensibility in the other metadata
              regimes I mentioned above.

              My model for doing this is still very rough, and I am already happily
              stealing clever ideas from the new RSS 1.0 draft and adding them in. The
              current document is very rough, and a bit embarassingly so. However, if
              anyone else is interested in pursuing this line of thought, I'd be happy
              to pass it on.

              Ian
              --
              Ian Graham ................ http://www.utoronto.ca/ian/
            • Aaron Swartz
              ... Do you think it would be possible to fit your information into RSS through the use of namespaces? Of course, ideally, we d like to have something like you
              Message 6 of 8 , Aug 15, 2000
                Ian Graham <ian.graham@...> wrote:

                > Most of this information is defined, in a limited way, in the various RSS
                > elements or attributes. However, I suspect that by abstracting these away
                > from being tied to the RSS 'channel' model, and by constructing a suitable
                > XML framework for generic syndication data, we can make a more extensible
                > specification that can encompass RSS 0.9x-style data in addition to other
                > forms, and that can also allow for extensibility in the other metadata
                > regimes I mentioned above.

                Do you think it would be possible to fit your information into RSS through
                the use of namespaces? Of course, ideally, we'd like to have something like
                you describe as the RSS spec, but RSS 1.0 is very concerned about
                backwards-compatibility. And since you do have the power of namespaces it is
                possible to use RSS for a number of different things. Can you give an
                example of something that you can't fit into RSS that would be supported by
                your format?

                I don't think fragmenting things further by creating yet another spec is the
                way to go. What exactly would you like to do with RSS and why doesn't it
                work right now. Perhaps this will lead us to a discussion about future RSS
                possibilities.

                --
                Aaron Swartz |"This information is top security.
                <http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
                <http://www.theinfo.org/> | - Marshall McLuhan
              • Rael Dornfest
                I ll echo Aaron s thoughts here... Please do write up what you d need and let s see how this might fit into RSS via what s already in the RSS core, XML
                Message 7 of 8 , Aug 15, 2000
                  I'll echo Aaron's thoughts here...

                  Please do write up what you'd need and let's see how this might fit into
                  RSS via what's already in the RSS core, XML Namespace-based modularization
                  and RDF -- that's what they're there for :-)

                  Rael

                  On Tue, 15 Aug 2000, Aaron Swartz wrote:

                  > Ian Graham <ian.graham@...> wrote:
                  >
                  > > Most of this information is defined, in a limited way, in the various RSS
                  > > elements or attributes. However, I suspect that by abstracting these away
                  > > from being tied to the RSS 'channel' model, and by constructing a suitable
                  > > XML framework for generic syndication data, we can make a more extensible
                  > > specification that can encompass RSS 0.9x-style data in addition to other
                  > > forms, and that can also allow for extensibility in the other metadata
                  > > regimes I mentioned above.
                  >
                  > Do you think it would be possible to fit your information into RSS through
                  > the use of namespaces? Of course, ideally, we'd like to have something like
                  > you describe as the RSS spec, but RSS 1.0 is very concerned about
                  > backwards-compatibility. And since you do have the power of namespaces it is
                  > possible to use RSS for a number of different things. Can you give an
                  > example of something that you can't fit into RSS that would be supported by
                  > your format?
                  >
                  > I don't think fragmenting things further by creating yet another spec is the
                  > way to go. What exactly would you like to do with RSS and why doesn't it
                  > work right now. Perhaps this will lead us to a discussion about future RSS
                  > possibilities.

                  ...
                • Ian Graham
                  I do agree with you both -- I don t really want to break with RSS compatibility ... and the new RSS spec reinforces some thoughts as to how to avoid doing so.
                  Message 8 of 8 , Aug 15, 2000
                    I do agree with you both -- I don't really want to break with RSS
                    compatibility ... and the new RSS spec reinforces some thoughts as to
                    how to avoid doing so. As to Aaron's comments -- I already believe
                    that namespaces are the way to do these things, but the key I think
                    is to define a minimal RSS 'syndication' format that can be expanded
                    upon using namespaces within each module or across modules. Alternately,
                    I am thinking of a 'syndication' framework that could 'contain' RSS
                    messages in a way that is backwards compatible with RSS 0.91 processors.

                    I know that is probably as clear as mud, but over the next few days I will
                    try and draft up something more sensible, and mail it out.

                    Best --

                    Ian


                    On Tue, 15 Aug 2000, Rael Dornfest wrote:

                    > I'll echo Aaron's thoughts here...
                    >
                    > Please do write up what you'd need and let's see how this might fit into
                    > RSS via what's already in the RSS core, XML Namespace-based modularization
                    > and RDF -- that's what they're there for :-)
                    >
                    > Rael
                    >
                    > On Tue, 15 Aug 2000, Aaron Swartz wrote:
                    >
                    > > Ian Graham <ian.graham@...> wrote:
                    > >
                    > > > Most of this information is defined, in a limited way, in the various RSS
                    > > > elements or attributes. However, I suspect that by abstracting these away
                    > > > from being tied to the RSS 'channel' model, and by constructing a suitable
                    > > > XML framework for generic syndication data, we can make a more extensible
                    > > > specification that can encompass RSS 0.9x-style data in addition to other
                    > > > forms, and that can also allow for extensibility in the other metadata
                    > > > regimes I mentioned above.
                    > >
                    > > Do you think it would be possible to fit your information into RSS through
                    > > the use of namespaces? Of course, ideally, we'd like to have something like
                    > > you describe as the RSS spec, but RSS 1.0 is very concerned about
                    > > backwards-compatibility. And since you do have the power of namespaces it is
                    > > possible to use RSS for a number of different things. Can you give an
                    > > example of something that you can't fit into RSS that would be supported by
                    > > your format?
                    > >
                    > > I don't think fragmenting things further by creating yet another spec is the
                    > > way to go. What exactly would you like to do with RSS and why doesn't it
                    > > work right now. Perhaps this will lead us to a discussion about future RSS
                    > > possibilities.
                    >
                    > ...
                    >
                    >
                    >
                    >
                    >
                    > To unsubscribe from this group, send an email to:
                    > rss-dev-unsubscribe@egroups.com
                    >
                    >
                    >
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.