"There's a big difference between 'mostly almost ready' and 'all almost ready'." -- Paraphrased from the Princess Bride

After a bit more thought and discussion, I've found there are a few more things I'd like to see in Atom before we call it 1.0. Nothing major, but a few loose ends that we can hopefully tie down without too much more trouble. Here's what I just sent to the mailing list:

* Links: I'd love to see this nailed down a little better, but my hope of reaching consensus is fading, and I don't know how much more energy I'll feel inclined to contribute to the effort. If we're going to punt on making this really good, but there are any minor tweaks that we CAN agree on, let's at least do those.

* PaceHeadInEntry: Is there any reason not to put this in? (Note: I think it could use an example of an aggregated feed--the only example it has now is Atom over XMPP.)

* Categories: Sometimes useful. Never problematic, as far as I can tell. Shouldn't be too hard to nail down the specifics. Let's put it in.

* Enclosures/Images (both "favicons" and other feed- or entry-related images): Although one might use HTML in the content to point to some of these, for CaRP (which displays newsfeeds on webpages), I find it extremely useful to have these in a separate element--it gives the user much greater flexibility in formatting the output. Of course, if the publisher wants an image to be displayed in a particular way in relation to the rest of the content, then pointing to it from within the content is necessary, but if they simply want to specify an image (or whatever) to have displayed alongside the content in some way or another, a separate element is preferable.

* Explicit entry deletion: Another "why not put it in". Yes, once you've published something, it's out there, and you can't expunge it completely, but Arve's use-case[1] for deletion shows that there would be a real benefit to having a deletion mechanism (assuming it would get implemented, which I expect it would). This should be easy enough to hammer out specifics for[2]. Let's do it.

* General Extensibility: I see no reason to rush to 1.0 without nailing this down better. On the other hand, I personally don't care much about the specifics, so I also see no reason to wrangle over them for a long time, if that's what would have to happen to get it done.

Antone

[1] http://www.imc.org/atom-syntax/mail-archive/msg11312.html

[2] I can think of two methods--perhaps these have already been discussed on the list--I don't remember. One would be to add a date construct as a child of atom:entry to mark a deletion date. The problem is, of course, that you have to send a complete entry to say that it's not there anymore. The other is to create a child of atom:feed that just indicates the ID of a deleted entry. A feed might contain a sliding window not only on entries, but another sliding window on the most recent deletions.