RE: Setting up a purl for rss/1.1, was: Re: RSS 1.1

What are the things that RSS 1.1 solves that people have been asking
for?  

The reality is that RSS is a mess, the problem is not utility but
confusion over too many names. RSS 2.0 has won mindshare, the technical
details of the standard are almost irrelevant. RSS 1.0 has some benefits
in some instances, but a much better focus for this group would be on
modules.

5 years later, new RSS modules are not read by a single aggregator and
there is no process or tools for building modules.

If 1.1 is not backwards compatible to 1.0, then 1.1 is poss. a
misleading name and it can't be called 2.0 etc.
Without backwards compatibility there is now yet another standalone
flavor of RSS/Atom, so the practical, end user benefits of the new
standard have to outweigh the drawbacks of confusion.

Therefore, as regards:
> >There have been a number of evolutions in 
> >both RDF and syndication since the RSS 1.0 specification was
released, 
> >which can be used to the advantage of the format."

If evolutions in RDF and Syndication allow for a new standard with much
better features that people users proactively asking for, then they
should be measured against the downside of yet more confusion amongst
users.



-----Original Message-----
From: Christopher Schmidt [mailto:crschmidt-ShfR2DvLQHoeIZ0/[email protected]] 
Sent: Sunday, January 23, 2005 8:58 AM
To: [email protected]
Subject: Re: Setting up a purl for rss/1.1, was: Re: [RSS-DEV] RSS 1.1


On Sun, Jan 23, 2005 at 04:16:19PM +0100, Reto Bachmann-Gmuer wrote:
> 
> Christopher Schmidt wrote:
> 
> >
> >>I guess asking this now would mix up following questions:
> >>- is an update needed?
> >>    
> >>
> >I think that this is a question that can be answered simply by
looking 
> >over the history of RSS 1.0. There have been a number of evolutions
in 
> >both RDF and syndication since the RSS 1.0 specification was
released, 
> >which can be used to the advantage of the format.
> >  
> >
> A good point. However the only use of newer RDF features I can see is
in 
> the payload module not in the core. You do use new RDF/XML features:

> -parseType="Collection": good,but doesn't solve the problems with
items

I'm not sure what you mean by this: what problems with items? It creates

an ordered list in RDF, but at the same time doesn't generate (much) 
syntactic cruft for tools which don't understand RDF. (Most aggregators 
that I've found do not use RDF to parse these files.)

> -omit rdf:RDF: makes it impossible to add arbitrary triples to the 
> RSS-Document

Since no source is going to want to aggregate these "arbitrary triples" 
anyway, why would allowing them make any sense? 

> So you gave up backward compatibility in an attempt to be
revolutionary. 
> Now you postponed revolution and that's the time to reconsider 
> compatibility. I think the ability to deprecate properties is a nice 
> feature and renders -in this case - a new namespace obsolete. on 
> http://esw.w3.org/topic/RSS I've fixed the RSS bugs my way, but you 
> could go much closer to the model you propose, the only exception is
the 
> image property, where I don't think it's possible to deprecate its
class 
> usage but not its property usage.

Using the same RSS 1.0 namespace is, quite simply, broken. The namespace

uses image as both a property and a class, which is prohibited by the 
OWL specifications. Using it is broken. However, the next draft of the 
RSS1.1 spec (which will be released tomorrow) will have informative 
mappings in OWL from RSS 1.0 to RSS 1.1, so tools which understand OWL 
will be able to understand the changes from RSS 1.0 to RSS 1.1.

Looking at the page on the ESW wiki:

The first example does not have any ordering in the items, as far as RDF

goes. There is no way to know what is the actual order, in RDF. This 
order is the entire reason behind the rdf:parseType="Collection" in the 
first place, and was also the reason behind the rdf:Seq. From an XML 
point of view, the "inChannel" aspect is far more extra syntactic cruft 
than the parseType="Collection" would be. 

Not only that, but as you say, this format doesn't work in old 
aggregators, so you're not keeping backwards compatibility. 

1. Breaking compatibility
2. Loss of ordering of items
3. Extra cruft via "inChannel"

Your second example still contains the only thing I really wanted to get

rid of with 1.1, the rdf:Seq element. I think that this aspect of RSS 
1.0 is the primary one which would cause content creators to "pass it 
by" for something simpler, so bringing that back is not an option I'm in

favor of.

I understand the desire to keep backwards compatibility, but both of 
these examples demonstrate problems in the way they're done: one with no

order in the RDF, the second with the rdf:Seq that has always been a pet

peeve with the specification.

I'm open to discussion on this, of course, and if the will of the 
community was against 1.1 as is, and towards something different, I'm 
sure that will be shown as time passes, but the problems I've outlined 
are the exact reasons why RSS 1.1 didn't go the way that you've
suggested 
in the first place.

Regards,

-- 
Christopher Schmidt



 
Yahoo! Groups Links



 





 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/