[rfc-i] Potential RFC format approach: HTML

Fred Baker fred at cisco.com
Fri Mar 23 23:33:21 PDT 2012


I personally would favor this, and I like the existing xml2html as instantiated at xml.resource.org (http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#anchor17) as a starting point. +1 on the supporting tool requirements.

Speaking entirely for myself, I'd actually like to see some more tools directly supporting the XML input format. Reason? Well, to pick one example, I have to file-scrape 1id-abstracts.txt to pull abstracts for internal discussion purposes at Cisco - which doesn't work all that well. "if there are two blanks at the beginning of the line, <>, as opposed to if there are four blanks" doesn't quite do it for me. If, however, I could extract <abstract><t>...</t></abstract>, I'd be golden.

Going to the HTML format would require agreeing to the RFC 2629bis format, or something derived from it. I'd again be in favor. There are a couple of things in there (tables) that I would want to tweak (could we vertical and horizontal lines between the boxes? and what could be done with annotations etc?), but I think it's 99% there.

On Mar 24, 2012, at 7:12 AM, Joe Hildebrand wrote:

> It should surprise nobody that I think HTML is a good fit for the
> requirements I've heard thus far for a new RFC format.  Here is a set of
> steps that might be able to get us there.
> 
> 
> - Subset HTML.  The subset would be decided upon based on current wide
> support, expectation that it will continue to work, repeatability, stability
> of output, etc.  However, as long as old-ish browsers can render the output,
> they might not need to get the full experience.
> 
> - Make the decision that the files will ALWAYS be encoded UTF-8.
> 
> - Define a very strict structure, using a microformat/semantic style, that
> makes it easy to pull out information semantically with a little bit of
> jQuery in post-processing tools.  Make a choice about XML-style
> well-formedness, which is probably not needed.
> 
> - Ensure that the document is self-contained, embedding styles and images,
> so that we can do signatures easily.  This means that newer files may look
> different from older files, and that's ok.  Greasemonkey or it's successors
> can swap in whatever styles you want.
> 
> - Define requirements for how we can add new capabilities over time.
> 
> - Define requirements for accessibility.
> 
> - Build libraries that know about the structure for several programming
> languages.  Survey folks that parse the current text format for their
> requirements.  It seems like JavaScript might be a good staring point.
> 
> - Write a tool that checks the HTML for the structure, then the several
> hundred nits that will grow up over time.
> 
> - Ensure that we know how to refer to pieces of the document in ways other
> than page and line number.  Doing this programmatically is easy with the
> right structure, but we may need to think about what humans do.  It may be
> easiest to just give the humans good tools to do review comments, like the
> WHATWG does.
> 
> - Ensure we've got good diff tools.  There are several adequate ones for
> HTML already.
> 
> - Tweak the output from xml2rfc to generate the agreed-upon structure,
> either for transition, or for people that want to have a high probability of
> passing the nit checks the first time.
> 
> - Begin the transition to HTML being the authoring format as well as the
> archive format.  Help people set up their graphical HTML editors to generate
> the structure.  With a good template, snippets, instructions, and hooks to
> the nit tool, this seems achievable.  It should also be possible to write a
> pretty comprehensive editing suite that runs right in the browser, if
> someone has the time.
> 
> - Spend a little money to hire a real designer to make the output sing.  The
> goals would be readability and the perception of expertise and stability.
> 
> - Allow the RFC Editor to start accepting HTML-formatted entries that pass
> all the nit checks.  For a transition period, the text format could still be
> required, but in order to get the tooling situation straightened out, the
> Editor would have to start accepting HTML-only submissions earlier than some
> might find comfortable.
> 
> There are likely other steps, and there's a lot of personal opinion strewn
> throughout this proposal, but I figured it would be nice to have a starting
> point.
> 
> -- 
> Joe Hildebrand
> 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest



More information about the rfc-interest mailing list