Anything to add?
Julian Reschke wrote:
05-C05, 4.15.3 processing model Update -06: I'm still confused by the text. For instance...
I agree that this section is gnarly. The editors will attempt to clarify
that section without making any normative changes, and will check with the WG to verify that no normative changes have been unintentionally introduced.
06-C01, 3.1.1 "type" Attribute thus *any* kind of change that encourages "xhtml" would be appreciated.
While there is no consensus in favor of changing the document to 'encourage' XHTML, more than one person has questioned the use of XHTML-Basic. I don't remember where this decision was made (Sam?). While I disagree that XHTML has a definite advantage over HTML, I am concerned that this choice will portray XHTML as somehow less capable, since the HTML section cites the more general HTML 4.01.
Graham wrote:
A quick bit of rewording would help. Currently it basically says "The type attribute may have the values..." three times with three different rules. Changing it to "On the summary element, the type atrribute may have the values..." stops the spec being apparently self-contradicting.
The editors erred in failing to incorporate this suggestion in -07. We'll get it this time.
Scott Hollenbeck wrote:
Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt instead of RFC 2234 and confirm that everything that was valid before is still valid. The IESG approved this document as a Draft Standard last week.
Will do.
Section 4: RFC 2045 is referenced. 2045 is on its way to being obsoleted by draft-freed-mime-p4 (in the RFC Editor queue) and draft-freed-media-type-reg (in last call). Can the more recent documents be referenced instead of 2045?
I think so. Will do.
Tim Bray wrote:
We do currently say that the schema is non-normative; having said that, a statement that there is no DTD and no validity requirement couldn't hurt.
Will add text to this effect.
Paul Hoffman wrote:
I'd really like to see some guidance in the document to describe what the IESG should look for. We're not atom experts, so it's going to be hard to determine what we should and shouldn't approve. Another paragraph will help future IESGs understand what they need to consider when reviewing requests.
Sounds reasonable. (I was erring on the side of not micro-managing the IESG.) Rob/Mark: please take a shot at some guidance for them.
Will do.
Scott Hollenbeck wrote w.r.t. the namespace:
Yes, we can do it this way. Just please add some text so that so that IESG reviewers understand that this is a known issue that we have a plan to address.
OK, will do.
Robert Sayre
