The Atom Format end-game

[Tim Bray <Tim.Bray@xxxxxxx>]

This represents the result of discussions between Paul and myself, and 
is our position as co-chairs of the Atompub WG.

Beginning with the conclusion:

1. We *must* finalize the format.  Our deadline is drawing near and we 
need to focus on the publishing protocol.
2. We are close to RSS2 feature-compatibility, we either adopt image & 
enclosure or make a conscious decision not to.
3. Based on the detailed analysis below from the mailing list, there is 
rough consensus that the only remaining point we MUST settle in the 
format is extensibility.   Likely MustIgnore can gain consensus support 
via PaceExtendingAtom, perhaps with some fine-tuning.  Which leaves 
MustUnderstand.  It is possible that PaceMustUnderstandElement might 
get in if we either convince Joe Gregorio or decide to declare rough 
consensus over his objections. Or maybe not. Co-chairs can live with 
either.

Basis for this analysis:

Hoffman: http://www.imc.org/atom-syntax/mail-archive/msg11315.html
- What's the Minimum Progress Required to Declare Victory?

Here's what was offered in response: [CO-CHAIR COMMENTS LIKE THIS].

Sayre: http://www.imc.org/atom-syntax/mail-archive/msg11327.html
- PaceFieldingLinks [ACCEPTED]
- PaceUpdatedDefinition [ACCEPTED]
- Extensibility

Parks: http://www.imc.org/atom-syntax/mail-archive/msg11323.html
 - atom:updated is currently required. I think this will lead to it 
being polluted with general "Last Modified" dates, severely limiting 
its usefulness. Seeing as it is not possible to make an element 
optional after v1.0, but it is possible to do the reverse, this one 
seems urgent. [REQUIRES A PACE, GIVE IT A TRY, WE'RE PESSIMISTIC]
 - The discredited atom:id canonicalization nonsense still stands 
[DITTO]
 - The use of terminology is very poor. For example, several elements 
define whether they can "change" or not. How can a server ever change 
something after it has been transmitted? What we mean to say is whether 
or not all instances of an entry should have the same value. [SAYRE 
ACCEPTED THIS AS AN EDITORIAL ISSUE]
 - ditto "permanent, universally unique identifier" [DON'T UNDERSTAND]
 - No discussion on how xml:space applies to content types [DO A PACE, 
MIGHT FLY]
 - type="TEXT" does not define handling of line breaks [DITTO]
 - No discussion on whether whitespace or parameters are allowed in 
@type [DITTO]
 - Section 6 "Managing Feed State" could be a key differentiator 
between Atom and RSS if it were written rather than dropped [DO A PACE, 
BUT WE'RE PESSIMISTIC]

Roundy: http://www.imc.org/atom-syntax/mail-archive/msg11318.html
 - 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. [AGREE WITH PESSIMISM]
 - 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.) [ACCEPTED]
 - 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. [PaceCategoryRevised ACCEPTED]
 - 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. [PaceEnclosuresAndPix 
ADDRESSES THIS]
 - 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. [PROTOCOL, NOT FORMAT]
 - 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.

Morin: http://www.imc.org/atom-syntax/mail-archive/msg11302.html
- Include schemas! [WE AGREE, BUT WE THINK WE'LL GET THEM SOON AS WE 
ASK, LOTS OF PEOPLE SEEM HAPPY TO VOLUNTEER]

Gregorio: http://www.imc.org/atom-syntax/mail-archive/msg11287.html
- Any mention of extensibility in the format spec.
- A feed level 'image' element, ala RSS 2.0 which, "Specifies a GIF, 
JPEG or PNG image that can be displayed with the channel." 
[PaceEnclosuresAndPix ADDRESSES THIS]