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

[Nico Williams <[e-mail]>]

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?

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

Nico
--