Re: RSS 1.1 usage of parseType="Collection"

Dan Brickley wrote:

>* Danny Ayers <danny.ayers@gmail.com> [2005-01-19 16:47+0100]
>  
>
>>>From a modelling point of view, the container/collection side of both
>>RSS 1.0 and 1.1 do seem a little troublesome. I'll pass on figuring
>>out the details here ;-) But both express membership and order in a
>>way that to me doesn't seem to fit very well with the domain model,
>>which seems generally to be what's at the feed URI at a given point in
>>time is a sliding window onto the conceptual feed comprised of all
>>items (ever).
>>
>>An early question - the 1.1 spec says "order of the [items] child
>>elements is significant" - but what is the significance (bearing in
>>mind that most RSS 1.0 feeds incorporate a dc:date)?
>>    
>>
>
>There are some feeds, eg. upcoming movies/concerts, job listings etc,
>where the most helpful ordering for users is related to the things 
>the docs in the feed describe, and not the dates of the linked documents 
>themselves. it's healthy for RSS to note that the ordering is important, 
>without specifying exactly which property of what is sorted to provide
>the ordering.  So 15 movies might be listed 'next first', rather than by 
>last-updated data of the 15 pages that describe those movies, for eg.
>  
>
In the RSS1.0v1.4 draft I wrote that the items are usually sorted by 
date, while this works for many use cases an extension module could 
easily define alternative sorting. For example making possible the 
following property in a channel off upcoming concerts:

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

reto

Received on Saturday, 22 January 2005 13:20:16 UTC