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

[Julian Reschke <[e-mail]>]

Am 27.02.2021 um 18:30 schrieb Nico Williams:
> On Sat, Feb 27, 2021 at 05:35:02PM +0100, Julian Reschke wrote:
>> Am 27.02.2021 um 17:09 schrieb Nico Williams:
>>> On Fri, Feb 26, 2021 at 09:44:09PM -0500, Daniel Kahn Gillmor wrote:
>>>> The toolchain to build draft-ietf-openpgp-crypto-refresh produces XML
>>>> that contains:
>>>
>>> There are only two possible correct answers, but historically it is
>>> impossible to get agreement on adopting either:
>>
>> At least three :-).
>
> Your third solution is not a solution.  It says stop trying to have
> rendered text distinguish between sentence-ending periods and not.  That
> is just unacceptable.
>
> Ah, there is a third solution, duh: use a Unicode widespace space after
> sentence-ending periods ( ).  It... might be just slightly less
> unpleasant than <sentence>:
>
>    Here's an example.&emsp; And here's the next sentence.&emsp; I had to
>    follow &amp;emsp; with a space because running on two sentences is
>    annoying.
>
>>>    - mark-up sentences, e.g.,
>>>
>>>        <sentence>D. K. G. wrote a post.</sentence>
>>>        <sentence>This follow-up might be controversial.</sentence>
>>
>> I'd be surprised if people would be willing to do this.
>
> Right, no one would or should want that.
>
>>>    - follow sentence-ending periods with two spaces (which does not mean
>>>      the the rendered output must also do the same, as it could use a wide
>>>      space instead), e.g.,
>>>
>>>        D. K. G. wrote a post.  This follow-up might be controversial.
>>>
>>>      i.e., `.  ` as a sort of mark-up
>>
>> Tricky, because it would change the whitespace handling inside <t>
>> (where currently multiple white space characters are always equivalent
>> to a single space).
>
> Is that XML or xml2rfc forcing that?

People rely on whitespace being insignificant inside <t> and similar
elements. For instance, for indentation.

So we would need an algorithm that can distinguish between what's
itentional and what is not.

>>> Instead many developers prefer to code up imperfect heuristics for
>>> sentence ending periods.  If you search relevant archives (e.g., this
>>> list's) you'll find that this is a periodic discussion.
>>
>> Yes.
>
> Yuck.
>
>>> Don your asbestos suits now.  Flame war incoming.
>>
>> The third answer is: stop trying to. Optimizing the plain text output
>> format really really is not important.
>
> Not acceptable.

I just opened a random ancient RFC I'm familiar with (2068), and it
hasn't two spaces after a sentence ending. At least not consistently.

So exactly when became this a "requirement"? And who determines what
"acceptable" for plain text output?

Best regards, Julian