Julian Reschke wrote:
-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..
Including that character is a smart idea, but I don't like the text itself. Mark and I will try to think of something, but suggestions are welcome.
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>
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"''?
This section needs to be reworked. It doesn't know what it wants to be. It mixes guidelines for producers with a processing model for clients.
- 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.
Agree. I grabbed the bibliography from resource.org, which doesn't include URLs for W3C specs. I figured there might be a reason for that.
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.
But that's so boring! OK, ok, I'll do it.
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.
Agree. Will fix for -07.
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).
Agree. Will fix for -07.
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).
Agree. Will fix for -07.
"...same name registered within the IANA Registry of Link Relations Section 9, and..."
Put the section reference into brackets.
Agree. Will fix for -07.
Robert Sayre
