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

Re: [syndication] Re: Thoughts, questions, and issues.

Expand Messages
  • Gary Teter
    ... ... Right. That makes perfect sense. I was about to take issue with your statement that rdf:about buys RDF support for free , but then I realized
    Message 1 of 18 , Aug 21, 2000
      on 8/21/00 12:49 PM, Ken MacLeod at ken@... wrote:

      > rdf:about, specifically, buys RDF support "for free", by explicitly
      > giving the resource URI that this channel or item refers to. In RSS1,
      > it's <link> that is redundant (and probably remains only for backward
      > compatibility).

      <snip>

      > I don't believe it adds any complexity, though. The complexity comes
      > from people _thinking_ they need to understand RDF to use the
      > rdf:about attribute. They don't, just copy <link> there and forget
      > about it.

      Right. That makes perfect sense. I was about to take issue with your
      statement that "rdf:about buys RDF support 'for free'", but then I realized
      that, yup, my parser will faithfully ignore that attribute if I'm not
      specifically looking for it. As for output, I guess it's not so bad to "copy
      <link> there and forget about it."

      >> But inchannel and rdf:about? Why do I want those? What's wrong with
      >> using XML's built-in ability to express that an item belongs to a
      >> particular channel? e.g., <channel><item/><channel> My XML code
      >> understands that construct no problemo.
      >
      > As it's been described to me, <inchannel> has less to do with RDF than
      > it does with compatibility with RSS0.9.

      Given these stats, from Ian Davis' 7/25 post, I'd argue strongly that
      backwards compatibility with RSS 0.90 is a red herring:

      RSS 0.90: 198 (11%, was 50%)
      RSS 0.91: 1439 (80%, was 46%)
      Other/Non RSS: 173 (10%, was 4%)

      RSS 0.91 is obviously the real-world version to be compatible with, and the
      RSS 1.0 spec makes that much harder.

      > I don't see any reason why an
      > RDF tool couldn't associate child elements with their parents.

      Agreed. But I do not need an RDF tool, I am not interested at this time in
      writing an RDF tool, I am writing code to get syndicated content into and
      out of our resource database.

      > I think the argument about <inchannel> maintaining information about
      > where the <item> comes from, in case the <item> is seperated from its
      > channel is a red herring. That _is_ a reason for having an
      > <inchannel> element _defined_ for an <item>, but not a requirement for
      > a) all items to have one even if they're embedded within a <channel>,
      > and b) that <item>s should be sibling or non-contained elements of
      > <channel>s. IOW, an RSS tool can easily add an <inchannel> element
      > only _when_ the <item> is removed from its <channel> (and any
      > aggregator or tool that doesn't is simply broken).

      I agree -- I think <inchannel> is just extra baggage that I don't see any
      reason to include, as long as you can enclose items within channels. But the
      current RSS 1.0 spec doesn't do that, which is why I'd like to see it
      removed.

      The reason I lump the <inchannel> in with the "RDF stuff" is that it
      wouldn't be necessary to include it if the spec simply used the old
      <channel><item/><item/></channel> construct. I blame that on RDF. :-)

      --
      Gary Teter, Big Dog
      Bulldog Beach Interactive http://www.bulldogbeach.com
      WireHose: The WebObjects portal framework http://www.wirehose.com
    Your message has been successfully submitted and would be delivered to recipients shortly.