atom:content (was: updated issues list for draft 07)

[Robert Sayre]

Julian Reschke wrote:

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"''?
Yes. In 4.1.3.3, you're supposed to apply them in order. Is that what 
you find confusing?

- 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? 
I don't know. We should be able to strike them, right?
Maybe it's not a SHOULD requirement after all?
In particular, that's a should against text/plain and text/html in @src.
Robert Sayre

updated issues list for draft 07

[Julian Reschke]

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

-06: 


"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

I think this should come with the following URL: 


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: 


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

06: 


"...same name registered within the IANA Registry of Link Relations 
Section 9, and..."

Put the section reference into brackets.
05-E12, 11 references

06: 


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 , 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

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 :-)