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

[Gary Teter <bigdog@bulldogbeach.com>]

on 8/21/00 12:49 PM, Ken MacLeod at ken@bitsko.slc.ut.us 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