I was looking over some old protocol discussions, and I realized that the current Atom entry syntax would be *perfect* for a lightweight format to iterate over collections of entries, were it not for the requirements around atom:summary.[0]
-----------------------------------------------------------------
atom:entry elements MUST contain an atom:summary element in any of the following cases:
* the atom:entry element contains no atom:content element. * the atom:entry contains an atom:content which has a "src" attribute (and is thus empty). * the atom:entry contains content which is encoded in Base64; i.e. the "type" attribute of atom:content is a MIME media type [RFC2045] and does not begin with "text/" nor end with "+xml". -----------------------------------------------------------------
I realize that text was battled over wrt to accessibility, but I have some pretty convincing use cases for dropping at least the first one.
Something like this:
<entry> <title>...</title> <id>...</id> <link ... /> <pub:edit ... /> <updated ... /> </entry>
would be a really nice way for basic clients to scan entries in the editing protocol. Current implementations stuff the whole entry in there, but you end up doing a GET on the editURI just to be safe. Also, without the summary, linkblogs become more doable.
I'd rather set a higher a bar for specs and include an "Accessibility Considerations" section, instead of mandating things like the html "alt" attribute does. After all, it takes human judgement to make something accessible.
Also, I might be inadvertantly arguing for something similar to the @profile proposals, but I hope not ;)
Robert Sayre
[0] http://www.atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.3.p.1
