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

Re: Why is RSS 2.0 Bad? (Not a Rhetorical Question)

Expand Messages
  • Marcus Campbell
    ... I agree. (Forgive me if I meander or am complete OT, but I fancy a go at posting...) When you talk on the phone you don t care how it works, you just know
    Message 1 of 19 , Sep 26, 2002
    • 0 Attachment
      > Because of this, I'm just saying that to be forever looking to simplify
      > the spec to a point where your average consumer can view source and
      > learn the spec is pointless and indeed harmful if done at the expense
      > of other stuff. Because on the internet, since HTML, the average
      > consumer has become a whole load more average.

      I agree.

      (Forgive me if I meander or am complete OT, but I fancy a go at
      posting...)

      When you talk on the phone you don't care how it works, you just know
      that you type in a number and you get to speak to someone. The actual
      transfer system is irrelevant to the user.

      Now, say you start sending video over the phone lines... do the users
      care that the specs and technology behind it get more complicated? Not
      as long as they only have to rely on dialing a number they won't, they
      just like the fact that they can see the person they're talking to.

      As long as the developers can, and do, make the video phones (and
      networks) then the user is happy. It could be a pixie in a box that
      uses magic pixie dust to get it to work. They shouldn't have to care.

      Similarly developers shouldn't need something that anyone and everyone
      has to understand. Nor should they make the basic format more
      complicated than anything they could _actually_ make use of.
      Developers should be able to make the tools that handle the data that
      creates the system. If they can't, they should be able to use someone
      else's tools. Even developers shouldn't have to resort to pushing raw
      data all the time.

      Making the specs extensible is good - very good - but that doesn't
      mean it's of any of use to argue its merits now or jump right in with
      modules that are only going to be useful some time in the future...
      maybe. Create the killer app. Get the format that works, works well
      and could be extended to work in future. It doesn't need to be
      overly-complicated or overly-theoretical and it doesn't need to be
      overly-"simple" (although I would like to see something without
      obsolete or proprietary bloat). It just needs to work.
    • mof-rss-dev@mfd-consult.dk
      Ben Hammersley wrote on Thu, 26 Sep 2002 02:38:11 +0100 ... I agree with your disagreement. The simplicity of HTML was great for its
      Message 2 of 19 , Sep 26, 2002
      • 0 Attachment
        Ben Hammersley <ben@...> wrote on Thu, 26 Sep 2002 02:38:11 +0100
        in :
        >An anonymous benefactor just privately pulled me up over this, citing
        >the common wisdom that the web was a success because "(HTML) was
        >transparently understandable to people with a minimal technical
        >background". It's a common argument for simplicity uber alles within
        >RSS.
        I agree with your disagreement.

        The "simplicity" of HTML was great for its quick widespread production,
        but as mentioned elsewhere, it's a pain to consume.

        This is, I believe, because simplicity is confused with "optional" and
        other lax definitions, either in the definition or the use.

        I would have thought that a lesson was learned there, that what is
        really needed is *strict* definitions, at least if it is in any way
        meant to be consumed by machines.

        I.e. a <description> element that is not defined as to its contents,
        and a <link> element that can point anywhere, is useless in practice,
        even though it's easy to produce.

        This is why I like vocabularies like the Dublin Core, which provide
        precise definitions for syntax and semantics. They may be somewhat more
        difficult to produce, perhaps needing date format conversion, but they
        are easily used.

        This is also why I dislike RSS 0.9x - it's too loose, it is unusable
        for anything *but* "the display of headlines in a browser for human
        consumption", and why I think that the path of RSS 1.0 is better.

        Why couldn't (X)HTML be used instead of RSS 0.9x?
        <html>
        <head>
        <title>My Blog</title>
        <meta name="DC.description" value="Various ramblings by Me" />
        </head>
        <body>
        <p>
        <a href="http://example.com/">
        <strong>Example "item" title</strong>
        </a>
        Example item description...
        </p>
        <address>me@...</address>
        </body>
        </html>
        And no, this is not a general suggestion for a new "competing"
        format...

        This may be the defining difference between the branches - the possible
        use of the "metadata" as *real* machine readable metadata for use with
        The Semantic Web(tm)?!?


        Regards,

        Morten Frederiksen
        ---
        A bird in the hand's better than one overhead.
        --
        <URL: http://www.mfd-consult.dk/ >
      • Libby Miller
        ... makes sense to me....looks somewhat like the xhtml profiles Dan Connolly has been using (and I ripped off for events module):
        Message 3 of 19 , Sep 26, 2002
        • 0 Attachment
          >
          > This is also why I dislike RSS 0.9x - it's too loose, it is unusable
          > for anything *but* "the display of headlines in a browser for human
          > consumption", and why I think that the path of RSS 1.0 is better.
          >
          > Why couldn't (X)HTML be used instead of RSS 0.9x?

          makes sense to me....looks somewhat like the xhtml profiles Dan Connolly
          has been using (and I ripped off for events module):

          http://www.w3.org/2000/08/w3c-synd/
          http://www.w3.org/2001/sw/Europe/200207/rsscal/xslt-rss-events.html

          Libby
        • mof-rss-dev@mfd-consult.dk
          Libby Miller wrote on Thu, 26 Sep 2002 17:18:48 +0100 (BST) ... True, that s much along the same lines, except for the fact that
          Message 4 of 19 , Sep 26, 2002
          • 0 Attachment
            Libby Miller <libby.miller@...> wrote on Thu, 26 Sep 2002 17:18:48 +0100 (BST)
            in :
            >> Why couldn't (X)HTML be used instead of RSS 0.9x?
            >makes sense to me....looks somewhat like the xhtml profiles Dan Connolly
            >has been using (and I ripped off for events module):
            True, that's much along the same lines, except for the fact that Your
            profiles are meant (?) to be embedded into a "real" HTML page, whereas
            I was suggesting a "lite" version (probably also suitable for PDAs and
            such).

            Of course, there is no reason as to why the "lite" version couldn't be
            a fragment of the "real" page.


            Regards,

            Morten Frederiksen
            ---
            Adhesive tagline. Lick this XXXX!
            --
            <URL: http://www.mfd-consult.dk/ >
          • Dan Brickley
            ... I think this could be a very profitable area to explore... The XHTML Basic spec s abstract, copied below, calls out some use cases that are close to those
            Message 5 of 19 , Sep 26, 2002
            • 0 Attachment
              On Thu, 26 Sep 2002 mof-rss-dev@... wrote:

              > Libby Miller <libby.miller@...> wrote on Thu, 26 Sep 2002 17:18:48 +0100 (BST)
              > in :
              > >> Why couldn't (X)HTML be used instead of RSS 0.9x?
              > >makes sense to me....looks somewhat like the xhtml profiles Dan Connolly
              > >has been using (and I ripped off for events module):
              > True, that's much along the same lines, except for the fact that Your
              > profiles are meant (?) to be embedded into a "real" HTML page, whereas
              > I was suggesting a "lite" version (probably also suitable for PDAs and
              > such).
              >
              > Of course, there is no reason as to why the "lite" version couldn't be
              > a fragment of the "real" page.

              I think this could be a very profitable area to explore...

              The XHTML Basic spec's abstract, copied below, calls out some use cases
              that are close to those we see with RSS and content syndication.

              http://www.w3.org/TR/xhtml-basic/
              [[
              Abstract

              The XHTML Basic document type includes the minimal set of modules required
              to be an XHTML host language document type, and in addition it includes
              images, forms, basic tables, and object support. It is designed for Web
              clients that do not support the full set of XHTML features; for example,
              Web clients such as mobile phones, PDAs, pagers, and settop boxes. The
              document type is rich enough for content authoring.

              XHTML Basic is designed as a common base that may be extended. For
              example, an event module that is more generic than the traditional HTML 4
              event system could be added or it could be extended by additional modules
              from XHTML Modularization such as the Scripting Module. The goal of XHTML
              Basic is to serve as a common language supported by various kinds of user
              agents.

              The document type definition is implemented using XHTML modules as defined
              in "Modularization of XHTML" [XHTMLMOD].
              ]]

              Similarities:

              * the need for a simple, restricted subset of content (for PDAs etc)
              * the need for it to be rich enough to support needs of content authors
              * architecture that supports principled, modular extension



              Another excerpt:

              [[
              1.2. Background and Requirements

              Information appliances are targeted for particular uses. They support the
              features they need for the functions they are designed to fulfill. The
              following are examples of different information appliances:

              Mobile phones
              Televisions
              PDAs
              Vending machines
              Pagers
              Car navigation systems
              Mobile game machines
              Digital book readers
              Smart watches

              Existing subsets and variants of HTML for these clients include Compact
              HTML [CHTML], the Wireless Markup Language [WML], and the "HTML 4.0
              Guidelines for Mobile Access" [GUIDELINES]. The common features found in
              these document types include:

              Basic text (including headings, paragraphs, and lists)
              Hyperlinks and links to related documents
              Basic forms
              Basic tables
              Images
              Meta information
              ]]


              My sense is that there are two main paths ahead for RSS-like formats: a
              data-oriented path, via RDF and the 'Semantic Web'; and a
              document-oriented path, via profiles of modular XHTML formats. The third
              'go it alone' path is one I'm finding less and less attractive. XML
              *allows* us all to create and promote new file formats; it's easy to slip
              from that into assuming that such proliferation of content type is a good thing.


              Dan


              --
              mailto:danbri@...
              http://www.w3.org/People/DanBri/
            Your message has been successfully submitted and would be delivered to recipients shortly.