[xml2rfc] xml:space in v3.rnc (Re: Insufficiency of txt format)

Carsten Bormann <cabo@tzi.org> Mon, 01 February 2021 17:41 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF203A1343 for <xml2rfc@ietfa.amsl.com>; Mon, 1 Feb 2021 09:41:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9EOQCuS_Ld1 for <xml2rfc@ietfa.amsl.com>; Mon, 1 Feb 2021 09:41:05 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF093A1342 for <xml2rfc@ietf.org>; Mon, 1 Feb 2021 09:41:05 -0800 (PST)
Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DTwGR1V1SzyXl; Mon, 1 Feb 2021 18:41:03 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <153F2EFE-0450-463C-B9D2-3601CD2F4E4E@tzi.org>
Date: Mon, 01 Feb 2021 18:41:02 +0100
X-Mao-Original-Outgoing-Id: 633894062.6728131-70244e25bbaea812cd3b7fe29bc12b6b
Content-Transfer-Encoding: quoted-printable
Message-Id: <3CE5C20E-1542-472C-AF7F-7A68C06F2CBE@tzi.org>
References: <20210130190821.7504E6D02AD4@ary.qy> <fcf04c37-7d63-337f-a434-92bb26aa27cd@alum.mit.edu> <rv7pcs$fv0$1@gal.iecc.com> <9739f26c-30d2-7b04-e866-b556c05ce07a@alum.mit.edu> <153F2EFE-0450-463C-B9D2-3601CD2F4E4E@tzi.org>
To: xml2rfc Mailing List <xml2rfc@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/klpCCKpyIK8aWth4vVdZrLY_Y44>
Subject: [xml2rfc] xml:space in v3.rnc (Re: Insufficiency of txt format)
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Feb 2021 17:41:08 -0000

On 2021-02-01, at 18:21, Carsten Bormann <cabo@tzi.org> wrote:
> 
> white-space handling

And while we are talking about this:

What the [insert Unicode characters here] is the story behind the two occurrences of xml:space in v3.rnc.

   spanx =
     element spanx { […]
       [ a:defaultValue = "preserve" ]
       attribute xml:space { "default" | "preserve" }?,

So, for a (legacy) <spanx> specifically, xml:space defaults to “preserve”.

For artwork:

   artwork =
     element artwork { […]
       attribute xml:space { text }?,

… it is allowed to set xml:space to any value (invalid in XML), but there is no default.  Also, xml:space is not allowed for <sourcecode>.

Contrast this to v2.rnc:

   spanx =
     element spanx {
       [ a:defaultValue = "preserve" ]
       attribute xml:space { "default" | "preserve" }?,

So this is unchanged in v3 from v2.

   artwork =
     element artwork {
       [ a:defaultValue = "preserve" ]
       attribute xml:space { "default" | "preserve" }?,

… makes sense if you think that xml:space is going to be useful at all.

This was discussed in <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/U7ounlQdYz95U3I-PofVgheYmPI>, but apart from agreeing that xml:space is useless, not much light has been generated.

There are a few more mentions further in history that I can find, but none of them really discussed how the situation of just <spanx> and <artwork> using xml:space and the v3 weirdness around this occurred.

RFC 7991 says:

   o  Deprecate the "xml:space" attribute in <artwork> because there was
      only one useful value.  […]

… and dutifully notes the above change in the RNC diff.  
Er, since only one value is useful, we allow any value and then let the default lapse to the non-useful one?

Most likely, there is no reason (because nothing actually is using this attribute), so this can be cleaned up, but I sure would like to know if there is.  Should an authoring tool generate any of these?

(There is also the SVG issue, which I’ll pass now.)

Grüße, Carsten