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@xxxxxxx> wrote: > > >--On Thursday, March 17, 2011 12:36 -0400 Tony Hansen ><tony@xxxxxxx> 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@xxxxxxxx >https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf