--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