Re: Thoughts, questions, and issues.

[Ken MacLeod <ken@bitsko.slc.ut.us>]

Gary Teter writes:

> Actually, I don't mind the namespaces. The big thing that I think is
> "unnecessarily" complicated is the RDF stuff -- inchannel and
> rdf:about.  Compared to 0.91, they're redundant, and it's hard to
> see why I need to include them when I'm wearing my "writer" hat.

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).

I suspect (but haven't asked the right people the right questions)
that RDF support could have been gained by using some type of external
RDF specification or XSLT transform, one that could, for example,
indicate that the <link> element provides the RDF resource URI that
the remaining RSS elements provide the properties (predicates) for.
By using an RDF attribute in the RSS1 file directly, tools can bypass
the indirection of using an external RDF schema or transform.  That's
just a guess though.

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.

> 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.  I don't see any reason why an
RDF tool couldn't associate child elements with their parents.

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).

  -- Ken