Julian Reschke wrote:
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.1.2>05-C01, 1.2 Example
Inconsistencies:
- version attribute (whitespace)
Will fix.
- "rel" attribute is missing
The rel attribute is optional and the relation is considered to be "alternate" in that case.
http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rel_attribute
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1>
05-C02, 3.1.1, "type" attribute
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";> Less: <xhtml:em> < </xhtml:em> </atomTitle>
(hope I got these right).
Nice, thanks.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1>
05-C03, 3.1.1, "type" attribute
"The content SHOULD be XHTML text and markup that could validly appear directly within an xhtml:div element."
Add reference to XHTML1 (<http://www.w3.org/TR/2002/REC-xhtml1-20020801>), section A).
I think mnot just fixed this for -06.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.3>05-C03, 4.3, atom:head
'The version identifier for this specification is "draft-ietf-atompub-format-05: do not deploy"'
Spelling of the version attribute inconsistent with section 4.1.1.
Will fix.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.11>
05-C04, 4.11 atom:host
Like others, I'm not sure I understand what this is for. I think one sentence of rational would make the spec easier to absorb.
Will try to fix.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.2>
05-C04, 4.15.2 atom:content
Like others, I find the syntactic impact of allowing it either to be in-line or out-of-band confusing. I don't feel strongly about this, but using two distinct XML elements instead might make things easier.
"If the value of type begins with "text/" or ends with "+xml", the content SHOULD be local; that is to say, no "src" attribute should be provided."
I'm not sure I understand what this is for. It seems to discourage putting XML data out-of-band. Why?
I agree with statements you made in another email on this. I agree that we should try to explain the difference, so people like Graham can point to it when someone expects the two methods to behave identically.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.3>
05-C05, 4.15.3 processing model
"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?
It's a MUST, and not an editorial change.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.B>
05-C06, B RelaxNG schema
I tried to use the schema to validate a feed that I generated and had the following problems:
- my version of trang (20030619) didn't accept the Schematron rules -- what else do I need to use RNC as reprinted?
I left the Schematron rules in, but I'm not sure I should have. This is kind of tricky, because the ISO standard covers schematron, and Relax NG XML syntax. There's an update coming to cover the compact syntax, but I don't know if it covers schematron annotations (which are comments, in any case, right?), or if it will be done in time for us.
- the namespace name doesn't match the current one
Will fix.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.1.p.4>
05-E01, todos
For instance:
Recommend to do them using rfc2629bis's "cref" element.
Will look into it.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#W3C.REC-xml-infoset-20011024>
05-E02, Notational Conventions
Should't we refer to <http://www.w3.org/TR/2004/REC-xml-infoset-20040204/>?
mnot has already fixed this.
<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>
I don't want to refer to OASIS's 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.
OK.
05-E04, Atom Documents
"... relative reference [RFC2396bis] present in an Atom..."
RFC2396bis has been published as RFC3986.
Oops, I adjusted this reference right before I submitted it, but forget to get the web page. Now you know why the IETF has these pesky rules...
05-E05, 3.2.2 atom:uri
"The content of atom:uri in a Person construct MUST be a URI reference [RFC2396bis]."
Directly point to RFC3986's section (here: 4.1).
OK.
05-E06, 3.2.3 atom:email
"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).
OK.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.2>
05-E07, 4.2 atom:head
"The atom:head element MAY contain any namespace-qualified [W3C.REC-xml-names-19990114] elements as children."
I think we're overdoing it here a bit and loose readability. I suggest to remove the reference or move it to the end of the sentence.
Will fix.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.6.2>
05-E08, 4.6.2 rel attribute
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.
Will fix.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.6.3>
05-E09, 4.6.3 type attribute
"Link elements MAY have a type attribute, whose value MUST conform to the syntax of a MIME media type [RFC2045]."
Add pointer into RFC2025 (I believe: section 5.1)
I think you just mean point to the section. Will do.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.19>
05-E10, 4.19 atom:tagline
On reading this, it's not obvious to me how this is different from a atom:title element. One sentence of explanation (or even inclusion in the example) would be helpful.
Will try.
05-E11, 9 IANA considerations
Something is wrong with the references to RFC3023 (sometimes they appear twice, one time even three times in a row).
Already fixed.
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.references>
05-E12, 11 references
Here's a procedural question: if we have normative references to the protocol and the feed discovery documents, the spec won't get published until those are done, too. Is everybody aware of that?
Yep.
Robert Sayre
