Julian Reschke wrote:
> If you're concerned with the limitations of ASCII, I'd advise
> pushing for something that doesn't have these limitations,
> yet is open, stable and really widely available. Such as HTML
> 4 (strict).
<dreaming>
I love the new tools.ietf.org/html rfcmarkup magic. I also
love the new unpaginated xml2rfc output. And of course the
ordinary ASCII xml2rfc output. But obviously the process
XML -> xml2rfc -> ASCII -> rfcmarkup -> HTML loses some of
the details in the XML source.
xml2rfc has its own HTML output, but this doesn't reflect the
look and feel of a "real" RFC like rfcmarkup or what faqs.org
does. With a new xml2rfc HTML output "compatible" with the
rfcmarkup style there would be no losses. Where "compatible"
means precisely the same format as in the ASCII output, but
with links, #page-1 etc. anchors, and #section anchors, like
rfcmarkup.
In addition xml2rfc could offer further anchors and links,
anything rfcmarkup can't "see" because it works with the
plain ASCII text instead of the XML source.
Maybe it could also offer <b>, <i>, and <b><i> while still
creating monospaced <pre> output. Or rather content-based
style tags (reserving <u> for links it will physically be
bold, italics, or both. That works with even Lynx if the
monitor isn't monochrome)
Last but not least, if we'd "allow" that as the "normative"
output in addition to text/plain, then "and now allow also
UTF-8 for the author address in THIS text/html" is trivial.
This should also work with XHTML 1.0 strict or XHTML basic.
Matter of taste, I think that XML is simpler than SGML for
tools trying to do something with it.
</dreaming>
OTOH the MS Word / PDF idea isn't a dream, it's a nightmare.
Bye, Frank
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf