Hi,
I just reviewed my -05 issues list, and updated it based on the changes in -06:
05-C02, 3.1.1, "type" attribute
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1>
-06: <http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.1.1>, examples updated
Suggested examples for TEXT, HTML and XHTML: a title containing the string "Less: <", where the less sign displays emphasized when possible..
<atomTitle type="TEXT"> Less: < </atomTitle>
<atomTitle type="HTML"> Less: <em> &lt; </em> </atomTitle>
<atomTitle type="XHTML" xmlns:xhtml="http://www.w3.org/1999/xhtml";><xhtml:div>
Less: <xhtml:em> < </xhtml:em>
</xhtml:div></atomTitle>
(hope I got these right).
05-C05, 4.15.3 processing model
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.3>
-06: <http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.4.1.3.3>
"If the value of "type" ends with "+xml" or "/xml", the content of atom:content may include child elements, and SHOULD be suitable for handling by software that knows the indicated media type. If the "src" attribute is not provided, this would normally mean that the "atom:content" element would contain a single child element which would serve as the root element of the XML document of the indicated type."
The statement about the "src" attribute seems to be unnecessary given the SHOULD-level requirement to have local content (thus no "src" attribute).
"If the value of "type" begins with "text/" the content of atom:content MUST NOT contain child elements."
See 4.15.2: so is this a SHOULD or a MUST?
Update -06: I'm still confused by the text. For instance:
- is it intentional that 4.1.3.3 says ``If the value of "type" ends with "+xml" or "/xml"'', while 4.1.3.2 used ``If the value of type begins with "text/" or ends with "+xml"''?
- also, if content for +xml SHOULD be local (4.1.3.2), why does 4.1.3.3. point 4, make statements about situations where it comes with @src attribute? Maybe it's not a SHOULD requirement after all?
05-E02, Notational Conventions
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#RELAX-NG>
I think this should come with the following URL: <http://www.oasis-open.org/committees/relax-ng/spec-20011203.html>
Update -06: I think it would be good if all W3C references came with URLs.
05-E03, Notational Conventions
"A collected schema appears in an informative appendix."
(refer directly by section/appendix number). Same for some other intra-document references.
05-E05, 3.2.2 atom:uri
"The content of atom:uri in a Person construct MUST be a URI reference [RFC2396bis]."
06: <http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.2.2>
Directly point to RFC3986's section (here: 4.1).
Update -06: I still think that spelling out the section number will make it easier to actually locate the definition.
05-E06, 3.2.3 atom:email
http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.2.3
"Its content MUST be an e-mail address [RFC2822]."
Again, please refer directly to the definition. In this case, it seems to be section 3.4.1 (addr-spec production).
05-E08, 4.6.2 rel attribute
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.6.2>
06: <http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.4.2.9.2>
If we use (A)BNF syntax, the spec needs to say so and reference the definition normatively (for instance, RFC2234).
"...same name registered within the IANA Registry of Link Relations Section 9, and..."
Put the section reference into brackets.
05-E12, 11 references
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.references>
06: <http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.references>
Here's a producedural question: if we have normative references to the protocol and the feed discovery document, the spec won't get published until those are done, too. Is everybody aware of that?
Update -06: we still have a normative reference to the feed discovery spec, which, according to <http://tools.ietf.org/wg/atompub/>, has expired. If this reference is expected to stay in, we'll have to actually finish that spec as well :-)
Best regards, Julian
