As someone writing the document, however, I want to jump up a level.
I'm okay with using <h1>, <h2> etc for section titles.
I'm okay with using <p> for paragraphs.
But I do *not* want to have to worry about boilerplate stuff ever again.
Okay, possibly choosing _which_ boilerplate to use, but keep me away
from ID nits complaining about my mistyping that boilerplate stuff or
using an old version of it, etc..
I also don't want to worry about bibliographic references or tables of
content or other output content that should be filled in for me
I really only want to concentrate on the text of the document.
On 3/28/2012 4:38 AM, Iljitsch van Beijnum wrote:
> I'm still catching up, but let me cautiously agree with this.
> On 28 Mar 2012, at 10:16 , Larry Masinter wrote:
>> I'm leaning toward a marked up profile of HTML where the authoring format and distribution format is a canonicalization of the authoring format. That is, I think we could move away from XML/XML2RFC and instead have a "cleaned profile" HTML with a tidy-step that does the work that xml2rfc does but which is idempotent (i.e., the output is suitable for input and generates the same HTML.)
> I've been thinking in that same direction myself, but then go one step further, and require the HTML to be unobtrusive enough that you can still treat the file as plain text ASCII if you really want/need to, or just remove all the HTML tags and be back to usable text. A rough example:
> An FTP ALG for IPv6-to-IPv4 translation
> <h1><a name="abstract">
> blah blah blah
> bla blah blah
> we don't close paragraph tags!
> blah blah blah
> <h1><a name="copyright">
> Copyright Notice
> Copyright (c) 2011 IETF Trust and the persons identified as the
> document authors. All rights reserved.
> van Beijnum Expires January 9, 2012 [Page 1]
> Internet-Draft An IPv6-to-IPv4 FTP ALG July 2011
> This document is subject to BCP 78 and the IETF Trust's Legal
> This wouldn't allow for fancy HTML features, but loading this in a browser would give you a fairly usable reflowable representation, and of course a better HTML version as well as PDF and ePub can be derived because there is enough meta data in there to do the conversion unambiguously.
> However, we really need to figure out requirements and proceed from there.
> rfc-interest mailing list
> rfc-interest@... > https://www.rfc-editor.org/mailman/listinfo/rfc-interest