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

Re: A year-zero strawman.

Expand Messages
  • tappnel
    It is times like these that I realize, despite my best efforts to comprehend this stuff, I am utterly clueless and completely confused. As an XMLer that s
    Message 1 of 36 , Sep 19, 2002
    • 0 Attachment
      It is times like these that I realize, despite my best efforts to
      comprehend this stuff, I am utterly clueless and completely confused.

      As an "XMLer" that's worked in the corporate IT space developing
      solutions his entire professional career and then some, this is not
      going to fly. I'm all for exploring RDF in RSS, BUT my feeling is that
      it is an intriguing, but highly theoretical, concept. Developers will
      look at it briefly, roll their eyes, and say "forget it. I have to
      implement something that works now." That does not further RDFs cause
      one bit. I am of the opinion that if an RDF-friendly RSS format is too
      achieve any type of adoption, it has to be virtually transparent to
      the user initially. Overtime as the industry evolves more can be added on.

      So with all due respect to Jon, I don't like a lot of the strawman
      proposal that was posted to start this thread. (Do you know how many
      developers would scoff at having to specifically order tags in an
      item?) Not that they don't have technical merit -- they just won't be
      accepted in practice under the current climate.

      I ask the RDF advocates to consider that in order for RDF (and the
      whole semantic web for that matter) to take root, it will have to
      "crawl before it run."

      I liked Shelley's proposal with Sean Palmer's refinements.[1] Its not
      perfect. I don't think folding the Dublin Core in is ideal and the
      apparent redundancy of link and rdf:about needs to be clearly
      articulated. That said its something I can get my head around and
      advocate to others.

      What does everyone else think of that proposal? Can we please discuss
      it here now?

      <tim/>

      [1] http://groups.yahoo.com/group/rss-dev/message/3536
    • Bill Kearney
      ... I agree. I checked. Out of over 12,000 feeds just polled there are a grand total of 22 feeds that contain the URI for mod_content. Many of which appear
      Message 36 of 36 , Sep 21, 2002
      • 0 Attachment
        > The history of support for mod_content (there's now, what, one aggregator
        > that supports content:encoded out of the box) seems to say that it might be
        > a good thing to keep the rich description a bit closer to the core, though.

        I agree. I checked. Out of over 12,000 feeds just polled there are a grand
        total of 22 feeds that contain the URI for mod_content. Many of which appear to
        be doing it wrong. <sigh/>

        > A plain text description that's written purposely as a description is
        > generally fine, but a weblog post with the HTML stripped can be pretty
        > incomprehensible - strip out links, <blockquote>, and <s>, for example, and
        > it's pretty easy to end up with gibberish. Yes, ideally a tool producing RSS
        > would strip HTML intelligently, adding footnotes for links, replacing
        > <blockquote> with quotes, and I guess deleting the content of <s>, but most
        > blogging tool developers seem to be a long way from having that much time to
        > spare.

        Not to mention the very handy work being done in perl modules and the like can't
        be used up inside one particularly popular content generator. So those users
        are stuck with waiting for the developer to get around to doing it instead of
        being able to use existing works.

        > Persuading the developers of RSS readers that can handle the HTML to
        > support mod_content would go a long way toward persuading producers to keep
        > their HTML out of <description>.

        Agreed and getting them to use mod_content properly would be even better.

        For a developer like MovableType they could simply state that their "except"
        input box would not accept HTML markup, just plain text. This would give them
        an easy way to push a text-only description element without tag-stripping
        hassles. And since the design of MT already supports a two more input boxes the
        others could be used inside a mod_content element. Thus the smart work already
        done in MT can be quite easily adapted to using the content module. Other
        environments, since they don't support these multiple input methods are likely
        to have a much harder time of it.

        -Bill Kearney
      Your message has been successfully submitted and would be delivered to recipients shortly.