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

Brian E Carpenter brian.e.carpenter at gmail.com
Sun May 27 00:31:38 PDT 2012


Joe,

On 2012-05-26 17:41, Joe Touch wrote:
> On May 26, 2012, at 9:34 AM, Brian E Carpenter wrote:
> 
>> On 2012-05-26 17:18, Joe Touch wrote:
>>> Here's a good example of something that container editing won't allow:
>>>
>>> ---
>>> The interface between TCP and lower level protocol is essentially
>>>  unspecified except that it is assumed there is a mechanism whereby the
>>>  two levels can asynchronously pass information to each other.
>>>  Typically, one expects the lower level protocol to specify this
>>>  interface.  TCP is designed to work in a very general environment of
>>>  interconnected networks.  The lower level protocol which is assumed
>>>  throughout this document is the Internet Protocol [2].
>>>
>>>
>>> 1.5.  Operation
>>>
>>>
>>>  As noted above, the primary purpose of the TCP is to provide reliable,
>>>  securable logical circuit or connection service between pairs of
>>>  processes.  To provide this service on top of a less reliable internet
>>>  communication system requires facilities in the following areas:
>>> ---
>>>
>>> I just grabbed part of two different containers. That can be useful for context. Why prevent it?
>> Who's preventing it? You can carve out chunks from xml2rfc source files
>> in this way; I've done it often. What you have above is
>>
>>  <t>.....</t>
>>  </section>
>>  <section title="Operation">
>>  <t>.....</t>
>>
>> Drop that into an ongoing section in a new document and it will work fine.
> 
> 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.

Agreed, that is not necessarily portable. In some cases the human
would have to insert an extra markup tag. Exactly the same thing
can arise in structured programming languages, for the same
reason - break the structure, and the compiler complains.

>> It will even work fine if the section nesting level is different in the second
>> document. With MS-Word, dropping a Heading1 in the middle of a set of
>> Heading2s can spoil your afternoon.
> 
> Actually, that works just fine - it starts a new heading. If that's not what you want, go to outline mode and shift the text to the level you want it.

Yes, that is the inverse of the previous case. Sometimes when you play
with nesting levels, manual intervention is required, with or without
containment. Seems like a wash to me.

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

I think a system that complains about structural anomalies is a Good
Thing.

   Brian


More information about the rfc-interest mailing list