Looks good mikef,
Obviously you have been working on it since the post above as it validates without warning now with both feedValidator and Validome.
The use of <![CDATA is smart. That should have been the way I went!
The feed adds correctly to firefox and bloglines.
My only comment is I don't see any dates or TTL so the feed will not know how often to re-load (probably not a bad idea for pictures given the potential download use if refreshed regularly). But the aggregator will not be able to sort the pictures from oldest to newest. (Unless the snippet is choosing all relevant pictures to show and they are ALL new).
By the way, doesn't etogal have an 'date' field in the table for the date it is uploaded to the server? Just a thought.
Thanks Cris, the things I needed to fix were invalid URLs (some people had uploaded filenames with spaces in), relative URLs, and missing (or invalid) atom reference. To fix the first needs a patch to etogalthumbs, which I'd hoped not to need.
the feed also works with google reader (and my google), but I need to clean up the HTML presentation.
The date field in etogal isn't (necessarily) the date of upload - it could be the date that the picture as taken, if present in EXIF fields in the jpg file. In any case that's not what the date field was supposed to be for.
I checked the intended usage of fields at http://www.rssboard.org/rss-profile
and based on the data there decided not to worry about date, or to use a ttl vlaue.
The publication date was intended as an embargo date, though isn't used as such by readers
ttl is rarely used by feeds, and often ignored or misused by readers
The aggregator knows whether it has seen something before by the guid, not by comparing dates - the guids provided are unique, with the slight drawback that they are unique to the image; if the text description is changed the guid isn't. As far as I'm concerned, that's not an issue worth worrying about - and the date in the etogal table doesn't change if the text is editted either.
The feed provides the most recent images, newest first - its easy to do this etogalthumbs.
24 is an arbitrary number that I've used in testing - I may use a smaller number later, but the actual data in the feed is quite small (it only includes a link to the image, it doesn't embed it) so I'm not concerned about the load. (Local caching in the reader/browser should mean the images are only downloaded once anyway, no matter how many times they are viewed.