Ned,
On 11-03-24 9:48 PM, "Ned Freed" <ned(_dot_)freed(_at_)mrochek(_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.
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.
My experience has been the exact opposite. Markup syntax is a known
quantity
that is easily accomodated, especially if you use a markup-aware editor.
The
editor I use closes elements automatically, provides constant syntax
checks,
and lets me toggle sections of the document in and out of view.
It's been a very long time since I've given any real thought to the
supposed
difficulties of dealing with markup syntax.
But you are probably pretty experienced user and you probably spent some
time setting up your environment to get where you are.
I believe having to deal with markup syntax poses a significant barrier to
those not as experienced as you.
But page breaks... I have on more occasions than I care to recall spent a
swacking big chunk of time adjusting them. Fix one widow, an orphan
appears
somewhere else. And yes, I realize this is not really necessary for I-Ds,
but
when the breaks are really bad I just can't help but try and fix them.
It's been a very long time since I experienced any problem with
formatting. :)
That was in the old days when I used a separate Nroff compiler. Using
NroffEdit's side by side view of source and text has completely removed
that issue for me.
And I think that is true also for an inexperienced user.
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.
Brian Reid once came up with a nice term for what results when this goal
is
pursued to it's logical conclusion: What You Get is What You Deserve.
Great one.... And so true.
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.
The task may not be grim, but the end results of such exercises - and
there
have been a lot of them - usually are.
I believe you are right, looking in the mirror. But time changes. I think
this is an area where open source development and open source libraries
really has provided a revolution. If we start with creating the
specifications that would allow such tool to be created, then you don't
need a huge software organization and kazillions of dollar any more to
piece together something that actually could be really useful..
I know I'm an idealist.. I still believe in simplicity.
/Stefan
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf