IETF Logo Mail Archive

Re: [xml2rfc] [Tools-discuss] [Rfc-markdown] New xml2rfc release: v3.16.0

Marc Petit-Huguenin <marc@petit-huguenin.org> Fri, 20 January 2023 14:05 UTC

Return-Path: <marc@petit-huguenin.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 3B61CC1526E9; Fri, 20 Jan 2023 06:05:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpwvFIowMQUV; Fri, 20 Jan 2023 06:04:56 -0800 (PST)
Received: from implementers.org (implementers.org [92.243.22.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D081C15257F; Fri, 20 Jan 2023 06:04:56 -0800 (PST)
Received: from [IPV6:2601:204:e37f:a6af:d250:99ff:fedf:93cf] (unknown [IPv6:2601:204:e37f:a6af:d250:99ff:fedf:93cf]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 45F74AE232; Fri, 20 Jan 2023 15:04:53 +0100 (CET)
Message-ID: <4e6509a8-4eab-8280-103a-02ab58caafb1@petit-huguenin.org>
Date: Fri, 20 Jan 2023 06:04:50 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0
Content-Language: en-US
To: Carsten Bormann <cabo@tzi.org>
Cc: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Jay Daley <exec-director@ietf.org>, xml2rfc@ietf.org, tools-discuss <tools-discuss@ietf.org>
References: <CAD2=Z87EMetcpv66YY_b2+X1-yFy4cTpKMjPoJL=cH99c7P_Uw@mail.gmail.com> <9d719176-a4eb-7cce-e706-10325700531c@petit-huguenin.org> <F1A5624B-16D0-4463-AC5F-B0A03F3B94B6@ietf.org> <8f5a497e-4135-7c0c-46cb-c3fe4791e9f3@petit-huguenin.org> <c3b3064f-e505-f504-f258-06f0d824ed4b@it.aoyama.ac.jp> <147fb362-e522-8ad4-51e2-2363a6e0eeb8@petit-huguenin.org> <5EFC7B9D-05B7-4B33-8BC6-760E080E0B4F@tzi.org>
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
In-Reply-To: <5EFC7B9D-05B7-4B33-8BC6-760E080E0B4F@tzi.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------n3H5okHwM8LLY0Q0PRDQt7Cq"
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/rGvOjNsTX8yrUEytCm1m6bAhUgY>
Subject: Re: [xml2rfc] [Tools-discuss] [Rfc-markdown] New xml2rfc release: v3.16.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: XML2RFC discussion list <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: Fri, 20 Jan 2023 14:05:00 -0000

On 1/20/23 05:47, Carsten Bormann wrote:
> On 2023-01-20, at 14:16, Marc Petit-Huguenin <marc@petit-huguenin.org> wrote:
>>
>> <artwork> is one of the ways an example can be inserted in an xml2rfc document, so it could be used to clearly mark in a document examples that contain unlimited Unicode.
> 
> The fact that artwork is completely exempted from the shunned character checking of xml2rfc is a nice example why the RFC7997 handling in xml2rfc is completely misguided.
> 
> There is no indication whether artwork is normative or just supplies an example.
> 
> What we did in RFC 9290 was to move text about the example that would have been fine within a normal paragraph of text into an artwork element.  That “solved” the problem (but created others, due to some complexity of doing RTL-only artwork).
> 
> What other I-Ds are doing now is putting all their equations in artwork.
> The problem is that the text around those can’t really refer to α and β etc. that occurs in the equations.
> 
> The logical, and fully absurd, conclusion is to move the rest of the text into artwork elements as well.  Hey, we could use nroff to generate word-wrapped artwork elements...
> 

I will always agree with more formalism.  RFC 7991 should have been designed to make the implementation of RFC 7997 (among others) possible.  Then xml2rfc tool should have been designed to exactly implement that version of RFC 7991 (and RFC 7996, etc...).

What I see is a bunch of preschooler asking the teacher to remove the lines because it is too hard to color inside them.

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

v2.29.0 | Report a Bug | By Email | System Status