--On Thursday, March 24, 2011 02:14 +0100 Stefan Santesson
<stefan(_at_)aaa-sec(_dot_)com> wrote:
I can't escape the feeling that this discussion of using
markup language editing to produce RFCs, is a bit upside down.
I'm much more concerned with draft writers having to deal with
markup syntax than I am about drafters trying to put a page
break in a sensible location, or format their text in a
readable fashion.
...
Stefan,
Parts of this are just a matter of taste. While I have
learned to prefer generic markup approaches over formatting
markup, I certainly started with the latter (if you know nroff's
history, I used runoff on CTSS). And I've done a good many
Internet Drafts (including several that evolved into RFCs) in
emacs and its clones: fancy formatting, page headers and
footers, etc., have never been requirements for I-Ds. I used
TeX and LaTeX for a while, still prefer them for some
applications, and miss a few of their features for some
Internet-Drafts and RFCs.
I actually tried to be neutral about the issue in my note, but
let me be more explicit. If nroff works for you, please use it.
My first priority in these discussions is to push back on any
effort to require a particular formatting tool or set of macros
for I-Ds, regardless of what that tool might be.
The latter is not a problem that consumes a lot of energy,
neither do I believe that drafters concern with readability is
a matter that causes the RFC production center a lot of
headache. So why is this a matter of concern?
I honestly think people waste a lot more time trying to figure
out how to properly form correct markup syntax, than they do
with format tweaking.
I think it depends on the person and sometimes on the document.
As I said, I've gradually learned to prefer generic markup, but
I'm definitely not inclined to impose that on anyone else.
What I'm opposed to, and what prompted my note, was purely what
I consider a misguided effort to turn the xml2rfc model from
generic markup into a formatting language. My own intuition,
based on some experience with more traditional publications but
without having discussed this with either the RFC Production
Center or the RSE (the latter because we still don't have one),
is that we are actually better off having roughly-formatted and
roughly-edited documents passed off to the RFC Editor staff and
letting them do final technical and copy editing and page
layout. From my point of view, that is called "letting the
professionals do their jobs".
I agree with John Levine's comment that whatever you know
already and are used to using is better. What I think of his
"dead end" option is irrelevant. You should use what works for
you. I will probably admire your nroff tools but am unlikely to
use them. I will use what works for me and won't try to
convince you that you should switch. And we both should oppose
anything that forces everyone into a single set of tools for
preparing I-Ds.
In my ideal world, where XML would work at its best, drafters
would concentrate on writing text in a fashion that could be
captured into XML (or any functional markup language), making
XML the output of the editing process rather than the input.
Well, then, we agree almost completely. In my ideal world,
people doing drafts would do as little markup as possible. I
think there are still advantages to identifying some things,
especially comments and placeholders) as what they are. YMMD on
that subject, or you may have a different list. I don't think
xml2rfc is ideally designed from that standpoint, for some
reasons that are inherited from XML and some that are exclusive
to it. I don't have the time or energy to redesign it and I'm
not sure I could do much better (although I'd probably make a
different set of what are, IMO, mistakes).
However, if carried to anything near its limit, that gets one
back to the "edit in emacs (or another plain-text editor of your
choice) and then hand things off to the RFC Editor staff" model.
If I were posting a few I-Ds a year --too few for me to remember
how to use xml2rfc efficiently-- and were not doing many of them
in collaboration with others, I'd probably go back to it.
That way it would not hurt the drafters if the XML syntax was
extended to capture both content and format, making it a
complete input to the rendering process.
Given the rather primitive structure of RFCs, writing such
editor seem not to be such a grim task. I'm even tempted to
provide one in the next major version of NroffEdit, where you
could choose nroff and/or XML as markup, but never bother with
it when writing your draft.
If the XML syntax was expanded to capture formatting then that
could indeed render nroff obsolete . Right now I would have to
keep relying on nroff to ensure that the document is rendered
as written.
Again, if the XML2RFC syntax were "expanded" to specify
formatting, it would seriously break the generic markup model
that inspired XML and its main predecessor. That would not,
IMO, be an improvement.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf