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

[Ian Graham <ian.graham@utoronto.ca>]

On Wed, 16 Aug 2000, Aaron Swartz wrote:

> Hello Dave, thanks for sharing your side of the story. Hopefully RSS can
> come to a resolution, but if not, it's good to hear your point of view.
> 
> Dave Winer <dave@userland.com> wrote:
> 
> > Why don't we just adopt what they're using and add it to RSS?
> 
> I think that the idea behind the use of namespaces is that we get the
> benefits of both. If someone wants to use RSS in a way that hasn't been
> approved by the "RSS tribunal" or whomever is managing the spec, they can do
> it, in a way that won't affect anyone else. (That way we get the benefit of
> movement and things don't get to slowed down or stagnated.) If we want to
> keep a stable core base, which people understand and agree on and is widely
> accepted by the aggregators, we can do that too, by having agreed-upon and
> approved modules.
> 
> The point is that we're not trying to prevent anyone from doing anything, by
> saying that can't modify the spec. If they want to add something to it, they
> can go right ahead and do it. If we want to keep an "approved" portion of
> RSS, we can do that too, but not at the expense of other development.

I agree with this, but am afraid that without some superimposed semantics
from RSS (or whatever it ends up being called), the namespace mechanism
will lead to messy and unwieldy 'extended' RSS files. To my mind the goal
should be a design such that, if you don't know the namespace-extended
portions, you can still usably process the 'core' RSS (or whatever) data
in the message - and, moreover, that the core should be really obvious
and simple to use/understand.

Thus I want to go back to basics and ask the question: what discrete sets
of information are used in an RSS/syndication message, and what is the
essential data in these sets and the relationships between them.  The sets
I see are:

  * access information (where did this resource come from, and how
    do I go get it again)
  * syndication rules (when should I start/stop displaying the data;
    how often is it updated, etc.)
  * cataloguing/indexing metadata (taxonomy data:  categories, keywords,
    human language of it, description)
  * metadata (date resource was created/last modified, main data type
    for the resource, authority data [who is the author/owner],
    copyright data, content rating info, etc.]
  * the data itself (whatever is being sent -- probably has many
    parts to it, each of which could have the preceding data associated
    with it)
 
I'd then like a core syntax that expresses, using a small RSS tag set, the
'core' aspects of each set. Namespaces could then allow for extensions
upon this set. 

In this sense, I see work on understanding the correct 'modules' to build
[as in http://purl.org/rss/1.0/modules/] as something that should happen
before RSS is redrafted....

> Does this make sense? I'm not sure I quite understand your concerns, but I'd
> love to hear them.
> 
> Thanks,
> 
> -- 
>         Aaron Swartz         |"This information is top security.
> <http://swartzfam.com/aaron/>|     When you have read it, destroy yourself."
>   <http://www.theinfo.org/>  |             - Marshall McLuhan            
> 
> 
> 
> 
> 
> 
>