[rfc-i] Comments on draft-hildebrand-html-rfc-2012-07-07 and draft-hoffman-rfcformat-canon-others-03

[jhildebr at cisco.com (Joe Hildebrand (jhildebr))]

On 7/30/12 2:06 PM, "Tim Bray" <tbray at textuality.com> wrote:


>My first really careful review of these documents, let?s call them
>?hoffman? and ?hildebrand? for short.
>
>First: Both could work.
>
>Hildebrand omits a lot of details about workflow and assignment of tasks
>that is usefully covered in hoffman.   I think my ideal outcome would the
>the workflow and polices described in hoffman, only with a canonical
>format as described in hildebrand, as
> opposed to the much-hated rfc2xml format.  As soon as you start to
>?improve? that, you?re going to be on a slippery slope, so why not jump
>all the way to a basic simplified HTML, which has already been designed
>by other people, is easy to view directly, and for which the software
>tools are rather fully debugged.

I agree with all of that.

>3.1 Syntax
>
>- why pretty-printing?  This offers no benefits to people who want to
>process the text automatically, adds extra work at authoring time, and as
>a person who works regularly with HTML/XML source, it?s not obvious that
>it really gives much benefit to source readability.

The intent was to try to ensure that if we were using slightly different
tooling from one another, those tools would generate less spurious diffs
after processing.

I don't care about this point much, and would be willing to remove the
requirement to pretty-print.

Does anyone else have an opinion?

>3.2.6
>
>- I?d leave out <strong>, require that all emphasis be with <em>,

Fine.  The RFC editor could also issue editorial policies along those
lines.

>that <i> be used only for foreign words,

I can add that; do you have a reference to that being common usage so I
can point to it?

><cite> where appropriate for titles,

Fine.

>and <b> not at all.

Anything not explicitly permitted is not allowed.  Otherwise, I'm not sure
how to think about the security of a document that I generate, induce you
to rsync, and get you to run from your local disk with non-Internet
sandboxing.

>If people really think we need two levels of emphasis, bring back
><strong> but still leave out <b>.

+1.

>3.2.11
>
>- I'd recommend requiring <p> inside of <li>. E.g.
>
><li>
>  <p>My first point.</p>
></li>
><li>
>  <p>My second point, which introduces complexification.</p>
>  <p>HTML does the paragraphs nicely and this is really useful.</p>
></li>

I'm fine with that.  It also cleans up the table of contents question.

>3.3.1
>
>- Change ?on submission? to ?on publication?. No point making the author
>package it all up, which is going to make it harder for the RFC editor to
>work with. I?m not even sure the relative-URI requirement is useful at
>the pre-publication phase - just require
> the doc editors to make sure the PNGs are reachable by anyone who wants
>to see them, leave the packaging work to the RFC Editor

I'm ok with that.  What I think I'll do is take out the language that
specifies when it happens altogether, and leave this as a workflow problem.

>3.3.4
>
>- Also, <pre><code> works for code blocks, producing the effect you?d
>probably like.

I'll experiment.

>- I suggest forbidding CDATA sections

I like that.  Will add to the syntax rules.

-- 
Joe Hildebrand