Re: [xml2rfc] assuming that period (.) ends a sentence is sometimes wrong

[Paul Kyzivat <[e-mail]>]

On 2/28/21 4:59 PM, Brian E Carpenter wrote:
> On 01-Mar-21 09:55, Paul Kyzivat wrote:
>> On 2/28/21 2:51 PM, Brian E Carpenter wrote:
>>> On 01-Mar-21 06:54, John R Levine wrote:
>>>>> Provided it doesn't also lose alternative Unicode whitespace characters,
>>>>> using   is an option. In a pinch we could have an element to mark
>>>>> the end of a sentence (<s/>).
>>>>
>>>> At the end of every sentence? That's, uh, quite a stretch. Are we sure
>>>> this problem is worth that much effort by every author?
>>>
>>> Since we're designing on the hoof here, I suggest you'd need a construct like
>>> <literal value="Philip R. Zimmermann"/>.
>>>
>>> But much simpler to scrap the double space rule.
>>
>> Two things are being muddled here:
>>
>> 1) two spaces at end of sentences in .txt output;
>>
>> 2) how two distinguish sentence endings by xml2rfc in xml input.
>>
>> There has been *some* discussion of using two spaces in the input for
>> (2), but it doesn't work that way now and there are many issues in
>> changing it to work that way. It isn't evident to me that it is a
>> serious proposal.
>>
>> *If* we had a reliable method for (2) then I doubt there would be much
>> issue with (1). The problem is that the existing method for (2) isn't
>> reliable.
>>
>> I haven't checked, but I presume the current problems (2) are also
>> exhibited in html output.
> 
> Why would they be? The html format has single spaces. (Just checked in
> RFC8981, which was announced half an hour ago.)

I didn't check, but gathered from the discussion that html had big 
spaces of some sort between sentences. That would seem to be the analog 
to two spaces in txt. And if we don't expect that in html then there is 
even less justification for the two spaces in txt.

>> ISTM that the real question is whether authors will be willing to
>> manually annotate the xml input to indicate sentence endings. I haven't
>> seen any proposal mentioned that I would willingly use on a regular
>> basis. I would rather suffer with the existing heuristic.
> 
> But much simpler to scrap the double space rule.

yes.