Re: Why the normative form of IETF Standards is ASCII

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



What I found strange that for many many years it was difficult to
get started on writing an I-D, because of a lack of a decent tool
to facilitate writing I-Ds.

The processing steps in producing an I-D are rougly this:

   1.  get document template
   2.  edit document
   3.  spell checking
   4.  convert authoring -> publishing format
   5.  display formatted output
   6.  make adjustments of document for nicer formatted output
   7.  idnits
   8.  submission


NRoffEdit does 1+2+3+4+5+6 for you automatically, intuitively, WYSIWYG.
You do *NOT* need to download, install or compile _any_ other software
besides a Java Runtime.  Just unzip and start the NroffEdit.jar.
And because it is Java, the usage is going to be fairly independent
of the underlying OS, which is a big plus for heterogeneous environments.


With xml2rfc 1, 2, 3, 4, 5 and 6 are all seperate, manual and painful
steps that require all sorts of unspecified other software and require
you to search around for information and read lots of stuff in order to
get it working.  The specific tools, their usage and the options to 
automate some steps from the above list varies significantly between OS.


Every author that wants to start writing his first I-D, will have
to go through this manual self-torture process when choosing xml2rfc:

   1. enter what you want to test into your document within your editor
   2. save file
   3. switch from editor to command line
   4. run xml2rfc processor on document
   5. switch between xml2rfc output and editor to fix xml2rfc reported errors
   6. save fixed file
   7. switch from editor to command line
   8. run xml2rfc procerror on document
   9. switch to visualization app
   10. load xml2rfc output into visualization app
   11. change your document based on output in visualization app


The orignal nroff approach was somewhat as complicated,
though there probably were more undesired formatting result rather
than nroff errors (saving you 5+6), and the nroff output could be
used directly as visualization (|more), obviating an additional app
for that (saving you 9+10).

But with the advent of NRoffEdit, that awkward processing issue
can be entirely avoided with the easy and intuitive nroff authoring
format -- you even get an english spell checker included.
All you need to know is described in the one-page summary
"Help->Supported" features of NRoffEdit plus the stuff that
"File->New draft from template" creates for you.

If anything deserves the description "60's style document editing"
then it is the current xml2rfc processing, which requires a whole bunch
of extra software, lots of manual processing steps, reading of lots of
documentation and plenty of time and desire for humiliation in order
to test all those features through the manual self-torture process.


My first encounter with TeX was in 1990 on an Amiga, and it came _with_
an editor where you could run your document through the TeX processor and
get it display (DVI graphics output on screen) with a single keypress.
Not WYSIWYG, but still quite usable.  And comparing the quality of
the printed output, none of the existing WYSIWYG solutions came even close.



In absence of an easy-to-use, single tool (preferably platform-independent)
to take care of most of the document editing, INCLUDING visualizing
the output, I see no value in considering an XML-based authoring
format for I-Ds and RFCs.


I do not mind that some people prefer using the xml2rfc approach,
and I am fine if they continue to use it.  But I do not like to
use that awkward document editing process, and I do not want the
IETF to force any authors to subject themselves to the xml2rfc
torture when there is running code (NRoffEdit) readily available,
that significantly facilitates document editing in the existing
format.


And btw. creating flowable HTML that might be easier to render
on mobile devices from the .nroff source should be very easy.


Even reflowing the existing paginated ASCII output should be fairly
simple.  What is missing in that output is the information about the
necessary amount of vertical whitespace between pages when removing
page breaks&header&footer lines.



-Martin
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]