ietf
[Top] [All Lists]

Re: Automatically updated Table of Contents with Nroff

2011-03-23 20:14:38
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.

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.

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.

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.

/Stefan




On 11-03-21 12:28 PM, "John C Klensin" <john-ietf(_at_)jck(_dot_)com> wrote:



--On Thursday, March 17, 2011 12:36 -0400 Tony Hansen
<tony(_at_)att(_dot_)com> wrote:

If we're going to put more work into xml2rfc, I would much
rather figure out what the production people are doing with
nroff that xml2rfc doesn't currenty do, and add twiddeles so
they can do that in xml2rfc and skip the nroff completely.

Yup, this exactly matches conversations I and others have been
having with the RFC production center.

Conversations along these lines have also been a part of why
there's the xml2rfc SoW currently in progress: to generate a
better code base from which modifications to xml2rfc can be
more easily made.

Tony,

While I believe this is a fine objective, I want to point out
one issue: the big advantage of generic markup (XML or
otherwise) over finely-controlled formatting markup (nroff or
otherwise) is that the former eliminates the need for authors
(and others early in the publication process) to worry about
formatting and, indeed, keeps them away from it.  The more one
goes down the path of letting (or, worse, encouraging or
requiring) authors fine-tune formatting and layout, the more we
reduce the advantages of generic markup.  In the extreme case,
xml2rfc could deteriorate into what might be described as nroff
plus a bunch of macros in an XML-like syntax.

I don't think we are there or that we are at immediate risk of
going there.  But I think we need to exercise caution.

In particular, if the idea is for the RFC Production Center to
be able to do detailed formatting (like page boundary tweaking)
using the general xml2rfc syntax and tools, I suggest that:

First, people think about whether there is a way to express the
requirements generically.   For example, a lot of the page
boundary tweaking that the Production Center has to do is
because the xml2rfc processing engine isn't good enough at
handling widow and orphan text.   If changes were made to the
engine to, e.g., bind section titles more closely to section
body text, and generally to permit the needed relationships to
be expressed better in generic markup, the requirement for
formatting-tweaking might be greatly reduced.

Second, if formatting control must be (further) introduced into
xml2rfc in order to make page layout control possible, can we do
it by inventing a processing directive family separate from
"<?rfc..."? If we had "<?rfc..." as something I-D authors were
expected to use a "<?rfcformat..." as something used only in
final formatting production, possibly even generating a comment
from nits checkers if present earlier, we would be, IMO, lots
better off --and lots closer to common publications industry
practice-- than mixing them together.

   john


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>