[rfc-i] How "modern" word processors do it

[Joe Touch]

On May 27, 2012, at 12:31 AM, Brian E Carpenter wrote:
...
>> It will not necessarily compile. Here's an example that fails:
>> 
>> ---
>> The TCP Authentication Option (TCP-AO) uses a TCP option Kind value of TBD-IANA-KIND. The following sections describe TCP-AO and provide a review of TCP MD5 for comparison.
>> 
>> 4.1. Review of TCP MD5 Option
>> 
>> For review, the TCP MD5 option is shown in Figure 1.
>> ---
>> 
>> In that case, you have:
>> 
>> <p>...</p>
>> <section title="Review of TCP MD5 Option">
>> <p>...</p>
>> 
>> That results in unbalanced sections.
> 
> I think you mean a case where the intended output is
> 
> 4. Outer section heading
> 
>    Some text.
> 
>    4.1. Inner section heading
> 
>         Some more text.

I meant:

	some text

	4.1. Inner section heading

		some more text

I.e.., grabbing the text without the outer section heading.

> Agreed, that is not necessarily portable. In some cases the human
> would have to insert an extra markup tag.

I eschew any solution that requires human editing of source code. For anyone who considers Word 20 years out of date, I consider editing source code for documents 30 years out of date.

> Exactly the same thing
> can arise in structured programming languages, for the same
> reason - break the structure, and the compiler complains.

Sure, but we're writing docs, not programming.

If writing an RFC rises to the level of programming, it's broken.

>> Word, BTW, never "doesn't compile" after a paste.
> 
> Indeed. In that way, it's dangerous, like FORTRAN IV or assembly language.
> It doesn't complain about anomalies.

When it pastes, it resolves the anomalies between the pasted text and main doc. You can't generate a Word doc with non-compile (or non-interpret) anomalies from a paste.

You may need to adjust what it gives you as a result - which, as you note, you have to do anyway, but at least you're not stuck debugging code.

Joe