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

Christopher Schmidt wrote:

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

The items are sorted by releaseDate by default since this is how rss is 
used in most cases, but it it possible to define alternative sorting 
orders by the use of extension modules. I've fixed the wrong description 
of the releaseDate property.

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

The first compact example is not compatible, but more compact than its 
counterpart following the previous spec. Chances that it happens to be 
understood by a poorly programmed aggregator are a bit better than with 
your proposal. But that's not my point, the second examples uses 
deprecated property to be compatible with old aggregators while 
containing every triple a new parse expects. This allows a smooth 
transition, without having just one more format.

>  2. Loss of ordering of items

I've mentioned a module to sort triples in an other order than by 
release-date on 
http://lists.w3.org/Archives/Public/www-rdf-interest/2005Jan/0183.html,

The following property of channel could be used to sort the elements by 
the value of another property

<rss-sort:sortAscending
rdf:resource="http://eample.org/ontogies/events#EventDate" />

Of course a module could also define a "collection" or seq-based 
ordering, but I don't think such a module would be widely adopted.


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

The second example contains deprecated statements to be compatible with 
old aggregators, newer aggregator should ignore the deprecated stuff. 
It's not possible to be compatible without "items", but it is left to 
the producer to make feed compatible or smaller and cleaner.

>
>  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 don't see that much difference between the "collections" and seq. But 
the problem is "items".

>
>  I'm open to discussion on this, (...)

me too ;-)

reto



 
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/