Hi,
I just updated my issues list based on the current draft (that is, I didn't yet have time to scan for potential new issues). Most of the issues are editorial, but two of them IMHO really need to be addressed before the draft can be submitted (05-C05 and 05-E12).
Also, the embedded RNC grammar now works for me with the standard Jing validator from James Clark's web site. Thanks!
Best regards, Julian
--
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-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>
"...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 :-)
06-C01, 3.1.1 "type" Attribute
<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.1.1>
This has been mentioned before...: as far as I can tell, it's far easier for recipients to process "xhtml" compared to "html" (no tag-soup parser needed), thus *any* kind of change that encourages "xhtml" would be appreciated.
Update -07: I acknowledge that the WG is unable/unwilling to look at this topic again after att the discussions we had about it earlier in. I'll leave it here inside my issues list anyway so that my disagreement is at least recorded :-)
