If you check the latest format draft (http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-06.txt), there are a bunch of open issues marked by the editor with "[[anchor"
We're going to need to sort out some of these before taking this forward. Paul did a run-through, sent it to me, and I've fiddled a bit, here are the results. There are 3 sections:
A. Things that don't require WG discussion but may require editorial action
B. Things that don't require any short-term action
C. Things that potentially require WG action
If you have feedback, *PLEASE* don't just reply to this message, the subject line isn't helpful. In particular, if you want to change some specific thing about the spec, we must have a separate thread.
======================================================================== ===
A. Things that don't require WG discussion but may require editorial action:
[[anchor4: Ask yourself: is the example atom:entry valid?]]
No, it's not, because there's no <summary> or <content>; so fix it.
[[anchor31: J. Reschke: I'm not sure I understand what this is for. It seems to discourage putting XML data out-of-band. Why? ... Explaining the issue instead of just trying to enforce it may lead to better results...]]
Agree that an explanation would be helpful, and it would be nice to have it before last call.
======================================================================== ===
B. Things that don't require any short-term action
[[anchor7: discussion of white space]]
There were a couple of failed white-space Paces, just take this out.
[[anchor11: Some feel type attributes with different allowable values in different elements is confusing.]].
Yep, and they may be right. Haven't seen any Paces. It's not fatal, take this out.
[[anchor12: example atom entry w/ escaped markup]]
That should be given in the -07 draft, but can wait until after IETF last call if it is contentious or a whole lot of work.
[[anchor21: Substantially changed from format-05, review carefully.]]
Agree. :-)
[[anchor22: inheritance]]
This is a duplicate of anchor24, so lose it.
[[anchor45: Substantially changed from format-05, review carefully]]
Agree. :-)
The "atom:id" element conveys a permanent, universally unique
[[anchor67: Changed to MAY from SHOULD. Republishers might want to copy it. --R. Sayre]]
Hard to argue.
[[anchor71: update upon publication]] [[anchor72: update upon publication]] [[anchor73: update upon publication]]
Leave these in to give IANA a hint.
[[anchor85: This section should be removed before final publication.]]
Leave this in to give the RFC Editor a hint.
======================================================================== ===
C. Things that potentially require WG action:
[[anchor24: What if
there's a source-feed element? This is busted. We should make
author required for atom:feed and optional for atom:entry. No
inheritance co-constraints required. --R. Sayre]]Right, this seems broken on the surface. Let's get some proposed wordings. On the other hand if we decide to override the editors and put <atom:head> back, this goes away (right?)
[[anchor25: "atom:entry elements MUST NOT
contain more than one atom:link element with a rel attribute value
of "alternate" that has the same type attribute value." This
requirement predates @hreflang. Keep it? --R. Sayre]]Keeping it would be plausible. So would changing the language to say "with the same type and hreflang attribute values." The default action is to leave things as they are, so if you want a change, post separately with a wording.
o atom:entry elements MUST contain an atom:summary element in any of
the following cases: [[anchor26: Do these requirements reflect the
WG's decisions? --R. Sayre]]
* the atom:entry element contains no atom:content element.
[[anchor27: Net result: Atom entries MUST have an atom:summary
or an atom:content element.]]
* the atom:entry contains an atom:content that has a "src"
attribute (and is thus empty).
* the atom:entry contains content that 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".Yes, this reflects the WG consensus, and yes, the implication is that you need either summary or content. I could live with taking that out of Atom, but we need someone to make a formal proposal and build consensus.
