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

Julian Reschke <> Mon, 01 March 2021 11:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A97483A1A09 for <>; Mon, 1 Mar 2021 03:12:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8G_NByER5qze for <>; Mon, 1 Mar 2021 03:12:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D2203A1A08 for <>; Mon, 1 Mar 2021 03:12:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1614597160; bh=NHT+D73thm3mVoNS6WJTexe138uMgWBbqZIfc21pjBM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=NoEWkZI6pJHFVkFFCY4LwfjF6e8xINambzfm31UR++ZD1xVc9OYIrwWX30/2WsuwM bWHSkciIIgYXO9VuSp8JUM+Z9rpJjoPPWMrU0GUo1oYRcyvcD/qMQ+p4efRDA7iPlj 10kEioTw/ripnyTwBkEjCjetXjzbpaWxdBoO4j38=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx005 []) with ESMTPSA (Nemesis) id 1N49h5-1lymnu3Nlx-0104Eq; Mon, 01 Mar 2021 12:12:39 +0100
To: Carsten Bormann <>
References: <20210227191644.165F76F105E2@ary.qy> <> <> <> <> <20210228173825.GE30153@localhost> <> <> <> <> <> <>
From: Julian Reschke <>
Message-ID: <>
Date: Mon, 1 Mar 2021 12:12:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:30H1CAnVQkcxCpuaNkl9el7006Nn4gKZX43+Ldu/pWtpTDyPoiu BlPJuedOqOq905EOJ4tDNXLZVvvS9827hn52WmA2nsVhH47C2OmdlthdyX34pvO5XdRjhba h0QHkQBc2ljnna5Ud4plvrRIChG1W84/v33tvQUqA6QmBjba+Wvf1dfW85X32EIruFokVoj AmGD1cVnlOMRJp7YRACpw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:rqUEhqGN5IA=:uJ5MMfFo5h8rLUfHdXJHUM 2cVOGW2Xn8UvOTqTHeyQ0m5fkHv1NGSurfwNqLe+BYt3hNQZkcTmkkeXvTIdFgo7l3/bc8kNp i+mnBp/MUAoTuMGW21ZDmdETjPn9HwJeh0f4rJE5tOdxb/81wEnv6T0Yn7HlsLUmW0ofV8+T3 hwgfA5PiWNpSY40tv2qDNWtMSAbnG8tjAyzQlbb6khGVOcJ6vLM764DQTqSbYoqNJ348CfEZh it6voR69KDb8ZSNVrv7aVujYILuRLOHmYe68KFHb+EF+8eWqzr2NMM4iCzsPPx/90PkE4K7cA SE4LwTe3S+Rlp9rpw/opRNkrPnDgvFmZGNAeQ9mdonKhfeND0GFz5ioR47mQwGe8IKjqXRfwW xJvdir5kEBmPZGanNvHoNNLLRecLhn3xrElmxhNdH9IEcbBtEWw3P9kg6mOESyvf4dndsUtwG qQ69oEEtWpUIfbFnvn4k+Zav259O097C/8JIL/x4DwZDgQSimpD/qEkgdlgfU9uN5VTmC6BYc CN159eXwRfl9mMXr7hNr+asD/1w1WnyxFMmQtyHG3kFYuaXMqEqCgu542SG1VijMShL9tE3Fs f2IKKnpvLX0w2skWyXxe08Mj1BFztUVDAs/GlbH+OuugnHJx4+j18eVdnKoUD9c/gdjbre2Co yXnmRFO5Z0qTMLtu/wxqpdjmGGmHqdwQKoKWkktMp/Tayh5vNHejxNVtzW2dgxVphGJzwutTi Y3VFoEtGVlTBg+kAkCCkgR+LUB85rLUMl8idPlSl2Y2gMp2HiTiO7wAmhOjGWiZwuc36pS0J1 rEbCul8XzKp2yzPbeBrti7fReZxweESPiK4jL9cL19duFKBwjMcRC3mVNbKMppA6hY7UAqD2S kEWdvZ3OTRuBmsBErECw==
Archived-At: <>
Subject: Re: [xml2rfc] assuming that period (.) ends a sentence is sometimes wrong
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Mar 2021 11:12:54 -0000

Am 01.03.2021 um 11:58 schrieb Carsten Bormann:
> On 2021-03-01, at 09:33, Julian Reschke <> wrote:
>>> Double spaces in XML input are copied verbatim into the HTML (where they then are swallowed by the HTML processor), so it is not like the processor is not seeing them.
>> But do they survive the preptool step?
> Sure.
> A quick check shows that has about 318 in-line sentence end marks, and 101 end-of-line ones (this may or may not count ones at the end of paragraphs).
>> If so, that would IMHO be a bug.
> Can’t speak to that.
 > ...

I can only talk about what we *intended* to specify.

The only elements in the V3 grammar which have an implied xml:space
value of "preserve" are <artwork> and <sourcecode>. Thus, whitespace in
any other element is not significant. That also means, that the
preptool, when pretty-printing, should remove it (I might open a ticket
for that).

Changing the defaults for <t> (and similar elements) *would* be a
change. I'm not saying it can't be done, but given the fact that the
Style Guide has removed the requirements for 2SP, and furthermore
(the CMO is frequently referenced for RFC style questions), I would be
surprised if there was willingness to do this.

In any case: *if* the outcome was that we want to handle
space-after-sentence-ends differently, we absolutely should do this in
all output formats, not just plain text.

Best regards, Julian