Re: [xml2rfc-dev] --table-borders

Carsten Bormann <cabo@tzi.org> Wed, 26 January 2022 22:41 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84D73A2586; Wed, 26 Jan 2022 14:41:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 I7dqm6v4d-Pl; Wed, 26 Jan 2022 14:41:48 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1275E3A2585; Wed, 26 Jan 2022 14:41:47 -0800 (PST)
Received: from smtpclient.apple (p5089a6b7.dip0.t-ipconnect.de [80.137.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Jkdxh3PwBzDCbM; Wed, 26 Jan 2022 23:41:44 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <33F0F5FB-5CBC-4D6D-BFB7-18AC9798C720@ietf.org>
Date: Wed, 26 Jan 2022 23:41:43 +0100
Cc: Kesara Rathnayake <kesara@staff.ietf.org>, xml2rfc-dev@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <997C8D93-EF22-42D3-A0A4-9C04EDAEF464@tzi.org>
References: <Ye/CSVZZnKrN+T2K@miek.nl> <cf002966-48ee-06b3-cc60-e52a865743b3@staff.ietf.org> <33F0F5FB-5CBC-4D6D-BFB7-18AC9798C720@ietf.org>
To: Jay Daley <exec-director@ietf.org>
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/dv-hCyReaLi05RP6WDdiA_FQm7o>
Subject: Re: [xml2rfc-dev] --table-borders
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2022 22:41:52 -0000

On 26. Jan 2022, at 22:38, Jay Daley <exec-director@ietf.org> wrote:
> 
> Personally speaking, I agree with Miek that all formatting should be controlled within the document and not externally in the tool.  

+1.

> So yes, it should go and if the functionality is needed then it should be a new language feature.

Somebody wanted the —table-borders feature, or it wouldn’t have been implemented.
It would be interesting to find out for what document, but since the information is not in the documents, that may be hard to reconstruct.

Do we know if any RFCs are rendered with that feature?

What does the feature look like?  Too lazy to look it up/try it out at the moment.

Anyway, having a global flag on a document that changes formatting for all tables in that document is unspeakable.
Of course, it works for trivial documents that have only one kind of table in it.

Yes, information of this kind needs to be kept with the individual elements of the document that receive the alternate formatting.
Of course, we already have attributes for similar cases in the grammar, e.g. dl/@spacing (and, one could argue, dl/@newline), ol/@indent, ... — I didn’t try to make an encyclopedic list, but the ideology of semantic markup falls a bit short when one-size-fits-all formatting doesn’t quite work.

The fact that, without Henrik, we have grammar ossification, means that we probably can’t fix anything before we get a v3.1.
Let’s not forget to put these things in when it finally comes to that.

By the way, “tweaks" like this were one of the original motivations for having processing instructions in SGML…

Grüße, Carsten