From nobody Tue Jan 25 01:26:43 2022 Return-Path: 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 C04383A1472 for ; Tue, 25 Jan 2022 01:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20210112.gappssmtp.com 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 TVx6wsMAmdu0 for ; Tue, 25 Jan 2022 01:26:37 -0800 (PST) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0F23A1460 for ; Tue, 25 Jan 2022 01:26:37 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id jx6so29225590ejb.0 for ; Tue, 25 Jan 2022 01:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20210112.gappssmtp.com; s=20210112; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition; bh=AUXuXq7FY2IqX/Sgvrv+nT9EtnRU64c84F5SeI2lt+c=; b=JIeY3+CXjQElR0DrRbpWDJP8mgsD28cN1fGb/aBRouAOjhx5PfB7fCogOKvMEUQI2Q I+8l4jYAmbiYQVN3UG+Q7ji1AgsBS9m1pz6micSK3oRThVfl7oPLBkVKyfNcEcliaEae dolUN5JS8MjbG8QW3ekZX352RcUCacRt7gLMORfC2gIb3xGD+sSME0VkpWxLv34resWY GhdzY1ADsgltz4vjcZNFwp0h/sWpBhdwCc7HkoX4NjhLMFR+AEmJTB0zCn+eLnbeffEL jqOiVqZ/dOk/zQk/GOnMqkYG3kLc3wJvoub338M4T0WVaQWbv9C2VZZhiVB5QqG0GS5O 96YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition; bh=AUXuXq7FY2IqX/Sgvrv+nT9EtnRU64c84F5SeI2lt+c=; b=rVtDxfi1rZIaOh+wrjGPlUbyvUTULh+rcgu42xAtsxJCHwy+hq9fpC31uYT43YbLSN U14vRhANkHq+1AchriBvY05VZUc0KeF0QKCC8xPD82Dmtq50/AjTj+L3VYm3MqDkjisb 5lna4Ci6U/3JqIkp/s3hEGjvN8akSpAVIy8swQM/Otgrat0vX6mbj7AYBpL+G+pxTU0G APLkqWKhDfuws5/AND7Xcp6IB++qBQBFm+cOP57fb0E8GdWsY3oHKDIg9uSxL23jBgGP q5xKjuDmLeaNblUCgTeQRSAiMA2c85vEyWf4maDc4IYdpr/6Zcl5Fry1V+l+2bw+YcHH ZlHg== X-Gm-Message-State: AOAM530E92YA5w26ynwN2yWTGNqJFK3qFFSVAVkvt+YvrpfpGJNxGCJO mjeSK0+EW8LCfNIjFtByrPm3lXr83Gt91Q== X-Google-Smtp-Source: ABdhPJwp5yaq5Mn6knZoZVcQvH9b3kFm72FWAlcQOb5rpAIxISgdIDTVPUt2vg2KV2quHwX5DOHBjg== X-Received: by 2002:a17:906:2ac5:: with SMTP id m5mr12653755eje.206.1643102794890; Tue, 25 Jan 2022 01:26:34 -0800 (PST) Received: from miek.nl (dhcp-077-251-206-012.chello.nl. [77.251.206.12]) by smtp.gmail.com with ESMTPSA id bf21sm7935388edb.2.2022.01.25.01.26.34 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jan 2022 01:26:34 -0800 (PST) Date: Tue, 25 Jan 2022 10:26:33 +0100 From: Miek Gieben To: XML2RFC Dev Message-ID: Mail-Followup-To: XML2RFC Dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Archived-At: Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 09:26:41 -0000 Hello, xml2rfc has gained a --table-borders flag, which changes how tables are rendered (in text, didn't check the html). There is another way of changing how a document looks and that is the indexInclude attribute in the tag. I think/feel that any option that changes the look of the document should be included in the rfc tag? Or that we default to only one way of doing things. I.e. indexInclude only works when there are s so why not make it always true? This might involve more discussion for table borders... Regards, /Miek -- Miek Gieben From nobody Wed Jan 26 12:55:14 2022 Return-Path: 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 7ED003A230E for ; Tue, 25 Jan 2022 20:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=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 DuZMDucH-7HP for ; Tue, 25 Jan 2022 20:48:41 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBCC53A230D for ; Tue, 25 Jan 2022 20:48:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 766F84096D35 for ; Tue, 25 Jan 2022 20:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHGcgKjW1M0F for ; Tue, 25 Jan 2022 20:48:41 -0800 (PST) Received: from [192.168.1.198] (122-58-157-86-adsl.sparkbb.co.nz [122.58.157.86]) by ietfx.amsl.com (Postfix) with ESMTPSA id 186774096D32 for ; Tue, 25 Jan 2022 20:48:40 -0800 (PST) Message-ID: Date: Wed, 26 Jan 2022 17:48:39 +1300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:97.0) Gecko/20100101 Thunderbird/97.0 Content-Language: en-NZ To: xml2rfc-dev@ietf.org References: From: Kesara Rathnayake Organization: IETF Administration LLC In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Wed, 26 Jan 2022 12:55:13 -0800 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 04:48:44 -0000 On 25/01/22 10:26 pm, Miek Gieben wrote: > Hello, > > xml2rfc has gained a --table-borders flag, which changes how tables are > rendered (in text, > didn't check the html). There is another way of changing how a document > looks and that is > the indexInclude attribute in the tag. > > I think/feel that any option that changes the look of the document > should be included in > the rfc tag? Or that we default to only one way of doing things. I.e. > indexInclude only > works when there are s so why not make it always true? This might > involve more > discussion for table borders... > --table-borders flag only has visible differences in text mode [1]. Shall we stick with one border style for text outputs and get rid of this flag? --Kesara [1] https://trac.ietf.org/trac/xml2rfc/browser/trunk/cli/tests/valid/manpage.txt#L4159 > Regards, > > /Miek > > -- > Miek Gieben > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev > -- Kesara Rathnayake Senior Software Development Engineer - IETF LLC kesara@staff.ietf.org From nobody Wed Jan 26 13:38:20 2022 Return-Path: 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 D87053A1359 for ; Wed, 26 Jan 2022 13:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 5PPz0DlxgBOH for ; Wed, 26 Jan 2022 13:38:15 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0DE3A235D for ; Wed, 26 Jan 2022 13:38:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 45ADB4096D36; Wed, 26 Jan 2022 13:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlPwthMxmePj; Wed, 26 Jan 2022 13:38:15 -0800 (PST) Received: from smtpclient.apple (unknown [158.140.230.105]) by ietfx.amsl.com (Postfix) with ESMTPSA id B55C74096D30; Wed, 26 Jan 2022 13:38:14 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: Jay Daley In-Reply-To: Date: Thu, 27 Jan 2022 10:38:11 +1300 Cc: xml2rfc-dev@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <33F0F5FB-5CBC-4D6D-BFB7-18AC9798C720@ietf.org> References: To: Kesara Rathnayake X-Mailer: Apple Mail (2.3693.40.0.1.81) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 21:38:17 -0000 > On 26/01/2022, at 5:48 PM, Kesara Rathnayake = wrote: >=20 >=20 >=20 > On 25/01/22 10:26 pm, Miek Gieben wrote: >> Hello, >> xml2rfc has gained a --table-borders flag, which changes how tables = are rendered (in text, >> didn't check the html). There is another way of changing how a = document looks and that is >> the indexInclude attribute in the tag. >> I think/feel that any option that changes the look of the document = should be included in >> the rfc tag? Or that we default to only one way of doing things. I.e. = indexInclude only >> works when there are s so why not make it always true? This = might involve more >> discussion for table borders... >=20 > --table-borders flag only has visible differences in text mode [1]. > Shall we stick with one border style for text outputs and get rid of = this flag? Personally speaking, I agree with Miek that all formatting should be = controlled within the document and not externally in the tool. So yes, = it should go and if the functionality is needed then it should be a new = language feature. Jay >=20 > --Kesara >=20 > [1] = https://trac.ietf.org/trac/xml2rfc/browser/trunk/cli/tests/valid/manpage.t= xt#L4159 >=20 >> Regards, >> /Miek >> --=20 >> Miek Gieben >> _______________________________________________ >> xml2rfc-dev mailing list >> xml2rfc-dev@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc-dev >=20 > --=20 > Kesara Rathnayake > Senior Software Development Engineer - IETF LLC > kesara@staff.ietf.org >=20 > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev >=20 --=20 Jay Daley IETF Executive Director exec-director@ietf.org From nobody Wed Jan 26 13:55:33 2022 Return-Path: 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 2E72F3A2402; Wed, 26 Jan 2022 13:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.714, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 TOf5uZxAKwdJ; Wed, 26 Jan 2022 13:55:27 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4B23A23FE; Wed, 26 Jan 2022 13:55:27 -0800 (PST) Received: from [192.168.1.114] ([47.186.48.51]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 20QLtNML072610 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 26 Jan 2022 15:55:24 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1643234124; bh=8IZhc2r4VfxzMys7PXADGkd1dyOYdkTEierACfppNT4=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=QowGcRUJN4+RZcOwdObG+PDvVQVW72SigdaDWWF2aYCNg/1OOQ+0zAneXJ5IW0ZJZ NjjkkAJkeCtte853Xt+MBoj4ghF4Kh4GdESIQxCWHPLOoLRwP40XTA9sTQ2ynvh7BJ +FAzkOxIIxQjs5NsjRFnjWocmoFUISLf6aPpKRlc= X-Authentication-Warning: raven.nostrum.com: Host [47.186.48.51] claimed to be [192.168.1.114] Message-ID: <674b7b1f-5afd-f893-7573-1a4b93fc4ed8@nostrum.com> Date: Wed, 26 Jan 2022 15:55:18 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Jay Daley , Kesara Rathnayake Cc: xml2rfc-dev@ietf.org References: <33F0F5FB-5CBC-4D6D-BFB7-18AC9798C720@ietf.org> From: Robert Sparks In-Reply-To: <33F0F5FB-5CBC-4D6D-BFB7-18AC9798C720@ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 21:55:31 -0000 On 1/26/22 3:38 PM, Jay Daley wrote: > >> On 26/01/2022, at 5:48 PM, Kesara Rathnayake wrote: >> >> >> >> On 25/01/22 10:26 pm, Miek Gieben wrote: >>> Hello, >>> xml2rfc has gained a --table-borders flag, which changes how tables are rendered (in text, >>> didn't check the html). There is another way of changing how a document looks and that is >>> the indexInclude attribute in the tag. >>> I think/feel that any option that changes the look of the document should be included in >>> the rfc tag? Or that we default to only one way of doing things. I.e. indexInclude only >>> works when there are s so why not make it always true? This might involve more >>> discussion for table borders... >> --table-borders flag only has visible differences in text mode [1]. >> Shall we stick with one border style for text outputs and get rid of this flag? > Personally speaking, I agree with Miek that all formatting should be controlled within the document and not externally in the tool. So yes, it should go and if the functionality is needed then it should be a new language feature. > > Jay That was an anti-goal of the 779* design work, which intended to have the xml capture the semantics of the document, and not provide layout instructions. If we do as you suggest, that's a big shift in requirements on the vocabulary, and pushes for much more frequent vocabulary version changes does it not? There will also be (and have been) arguments about including _anything_ in the vocabulary that would influence the behavior of only one of the renderers. > >> --Kesara >> >> [1] https://trac.ietf.org/trac/xml2rfc/browser/trunk/cli/tests/valid/manpage.txt#L4159 >> >>> Regards, >>> /Miek >>> -- >>> Miek Gieben >>> _______________________________________________ >>> xml2rfc-dev mailing list >>> xml2rfc-dev@ietf.org >>> https://www.ietf.org/mailman/listinfo/xml2rfc-dev >> -- >> Kesara Rathnayake >> Senior Software Development Engineer - IETF LLC >> kesara@staff.ietf.org >> >> _______________________________________________ >> xml2rfc-dev mailing list >> xml2rfc-dev@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc-dev >> From nobody Wed Jan 26 14:41:53 2022 Return-Path: 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 In-Reply-To: <33F0F5FB-5CBC-4D6D-BFB7-18AC9798C720@ietf.org> Date: Wed, 26 Jan 2022 23:41:43 +0100 Cc: Kesara Rathnayake , xml2rfc-dev@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <997C8D93-EF22-42D3-A0A4-9C04EDAEF464@tzi.org> References: <33F0F5FB-5CBC-4D6D-BFB7-18AC9798C720@ietf.org> To: Jay Daley X-Mailer: Apple Mail (2.3693.40.0.1.81) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 22:41:52 -0000 On 26. Jan 2022, at 22:38, Jay Daley wrote: >=20 > Personally speaking, I agree with Miek that all formatting should be = controlled within the document and not externally in the tool. =20 +1. > So yes, it should go and if the functionality is needed then it should = be a new language feature. Somebody wanted the =E2=80=94table-borders feature, or it wouldn=E2=80=99t= 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, ... = =E2=80=94 I didn=E2=80=99t try to make an encyclopedic list, but the = ideology of semantic markup falls a bit short when one-size-fits-all = formatting doesn=E2=80=99t quite work. The fact that, without Henrik, we have grammar ossification, means that = we probably can=E2=80=99t fix anything before we get a v3.1. Let=E2=80=99s not forget to put these things in when it finally comes to = that. By the way, =E2=80=9Ctweaks" like this were one of the original = motivations for having processing instructions in SGML=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 26 14:48:24 2022 Return-Path: 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 215DC3A25C8 for ; Wed, 26 Jan 2022 14:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.793 X-Spam-Level: X-Spam-Status: No, score=-7.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_HI=-5, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com 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 1bY0cDkYdTXS for ; Wed, 26 Jan 2022 14:48:17 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389873A25C5 for ; Wed, 26 Jan 2022 14:48:16 -0800 (PST) Received: from [192.168.1.114] ([47.186.48.51]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 20QMmDYM079701 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 26 Jan 2022 16:48:14 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1643237294; bh=VpuZOUGx3vcOmfhEPmJVDXr5dOA/wggzP6laLOGeKhc=; h=Date:Subject:To:References:From:In-Reply-To; b=Yb2ph24FNlwmKgnHDWzagimmmEr7kICE1hNNP2xVW1Y+1BFZih9z8jbefRYNgdUp1 AU7oiwkqx6B3SOW7M3NKnRsueHAAbaqgQOg0aafrTyo5DdJWZ6zPii/xgDI6sdbd52 MDZLVUmTgIv4lA3fUM50Eyza73EeAMpu+a8tTOts= X-Authentication-Warning: raven.nostrum.com: Host [47.186.48.51] claimed to be [192.168.1.114] Message-ID: <1ee39a65-68e7-6388-fa6d-6364ff546751@nostrum.com> Date: Wed, 26 Jan 2022 16:48:08 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: xml2rfc-dev@ietf.org References: <33F0F5FB-5CBC-4D6D-BFB7-18AC9798C720@ietf.org> <997C8D93-EF22-42D3-A0A4-9C04EDAEF464@tzi.org> From: Robert Sparks In-Reply-To: <997C8D93-EF22-42D3-A0A4-9C04EDAEF464@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 22:48:22 -0000 On 1/26/22 4:41 PM, Carsten Bormann wrote: > On 26. Jan 2022, at 22:38, Jay Daley 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. The RPC asked Henrik to implement it as an experiment for a document, and it ended up not being used. > 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? None have. > > 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. Yes, that's why it wasn't used, ultimately. > 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. Well, it's not the lack of Henrik that has the grammar stuck - we _could_ start making changes, but the team put together by RSOC to figure out where the grammar should be going decided we should nail down the next grammar before moving the ball under the decision of what the next grammar should be. I'm personally in the camp that the grammar should be allowed to change early and change often, with good versioning, but I'm very much in the minority. > > By the way, “tweaks" like this were one of the original motivations for having processing instructions in SGML… > > Grüße, Carsten > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev From nobody Wed Jan 26 14:52:49 2022 Return-Path: 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 E6B313A25F2 for ; Wed, 26 Jan 2022 14:52:46 -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 CZ6E7We5lkDC for ; Wed, 26 Jan 2022 14:52:42 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4A03A25F3 for ; Wed, 26 Jan 2022 14:52:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 8DFB24096D36; Wed, 26 Jan 2022 14:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ_iBf3oo0vA; Wed, 26 Jan 2022 14:52:42 -0800 (PST) Received: from smtpclient.apple (unknown [158.140.230.105]) by ietfx.amsl.com (Postfix) with ESMTPSA id ADC9E4096D30; Wed, 26 Jan 2022 14:52:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: Jay Daley In-Reply-To: <997C8D93-EF22-42D3-A0A4-9C04EDAEF464@tzi.org> Date: Thu, 27 Jan 2022 11:52:38 +1300 Cc: xml2rfc-dev@ietf.org, Kesara Rathnayake Content-Transfer-Encoding: quoted-printable Message-Id: <725DB532-FB23-41C1-9AC4-10D2C020CAA4@ietf.org> References: <33F0F5FB-5CBC-4D6D-BFB7-18AC9798C720@ietf.org> <997C8D93-EF22-42D3-A0A4-9C04EDAEF464@tzi.org> To: Carsten Bormann , Robert Sparks X-Mailer: Apple Mail (2.3693.40.0.1.81) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 22:52:47 -0000 Double response: > On 27/01/2022, at 10:55 AM, Robert Sparks = wrote: >=20 >=20 > On 1/26/22 3:38 PM, Jay Daley wrote: >>=20 >>> On 26/01/2022, at 5:48 PM, Kesara Rathnayake = wrote: >>>=20 >>>=20 >>>=20 >>> On 25/01/22 10:26 pm, Miek Gieben wrote: >>>> Hello, >>>> xml2rfc has gained a --table-borders flag, which changes how tables = are rendered (in text, >>>> didn't check the html). There is another way of changing how a = document looks and that is >>>> the indexInclude attribute in the tag. >>>> I think/feel that any option that changes the look of the document = should be included in >>>> the rfc tag? Or that we default to only one way of doing things. = I.e. indexInclude only >>>> works when there are s so why not make it always true? This = might involve more >>>> discussion for table borders... >>> --table-borders flag only has visible differences in text mode [1]. >>> Shall we stick with one border style for text outputs and get rid of = this flag? >> Personally speaking, I agree with Miek that all formatting should be = controlled within the document and not externally in the tool. So yes, = it should go and if the functionality is needed then it should be a new = language feature. >>=20 >> Jay >=20 > That was an anti-goal of the 779* design work, which intended to have = the xml capture the semantics of the document, and not provide layout = instructions. If we do as you suggest, that's a big shift in = requirements on the vocabulary, and pushes for much more frequent = vocabulary version changes does it not? We have features such as the newline attribute in the
element that = appear to be layout only and Carsten has listed some others below. >=20 > There will also be (and have been) arguments about including = _anything_ in the vocabulary that would influence the behavior of only = one of the renderers. We already have that with the type=3D"svg" attribute of the = element, which is arguably has a much bigger impact than a table border. > On 27/01/2022, at 11:41 AM, Carsten Bormann wrote: >=20 > On 26. Jan 2022, at 22:38, Jay Daley wrote: >>=20 >> Personally speaking, I agree with Miek that all formatting should be = controlled within the document and not externally in the tool. =20 >=20 > +1. >=20 >> So yes, it should go and if the functionality is needed then it = should be a new language feature. >=20 > Somebody wanted the =E2=80=94table-borders feature, or it wouldn=E2=80=99= 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. >=20 > Do we know if any RFCs are rendered with that feature? >=20 > What does the feature look like? Too lazy to look it up/try it out at = the moment. >=20 > 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. >=20 > 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, ... =E2=80=94 I didn=E2=80=99t try to make an encyclopedic = list, but the ideology of semantic markup falls a bit short when = one-size-fits-all formatting doesn=E2=80=99t quite work. >=20 > The fact that, without Henrik, we have grammar ossification, means = that we probably can=E2=80=99t fix anything before we get a v3.1. We have the XML and Style Guide Change Management Team = https://mailarchive.ietf.org/arch/browse/xml-sg-cmt/ Jay > Let=E2=80=99s not forget to put these things in when it finally comes = to that. >=20 > By the way, =E2=80=9Ctweaks" like this were one of the original = motivations for having processing instructions in SGML=E2=80=A6 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev --=20 Jay Daley IETF Executive Director exec-director@ietf.org From nobody Wed Jan 26 22:40:27 2022 Return-Path: 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 AB9593A135A for ; Wed, 26 Jan 2022 22:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 eIHssBiyw-kL for ; Wed, 26 Jan 2022 22:40:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E563A135D for ; Wed, 26 Jan 2022 22:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643265615; bh=RCCmC/VP5mgU7zMHStaELb6tFRIlF5sQ/4Zw9jERbYs=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=D/lBe6q1QMvhv9Rt4GqN9LGM8NYRx+Ikd10oYYxG+4p+MnanMzw2WoqsfKHxbIObf Jm/qJ2GwoxMvXX7ZwCuVXoIZAgZkxcAuXfNgk13rwlRaBGzfobVJnu6EZRRsPFI/PQ N0hTZQGeVzEiZxOdAdOmtuJ3PVWSLS3+zBU7x1ao= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.20] ([91.61.54.37]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MtOKc-1mP7Q126iU-00usXA for ; Thu, 27 Jan 2022 07:40:15 +0100 Message-ID: <7f87902c-a5bf-43fa-5ab6-f76d92619d8f@gmx.de> Date: Thu, 27 Jan 2022 07:40:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 To: xml2rfc-dev@ietf.org References: <33F0F5FB-5CBC-4D6D-BFB7-18AC9798C720@ietf.org> <997C8D93-EF22-42D3-A0A4-9C04EDAEF464@tzi.org> <725DB532-FB23-41C1-9AC4-10D2C020CAA4@ietf.org> From: Julian Reschke In-Reply-To: <725DB532-FB23-41C1-9AC4-10D2C020CAA4@ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:/feO0iTgEUWsv3zjNvyuPIreDKet3mbKdLGyeExLBl3Kon0FOrq tcjmKXCmhM34e406izLztP3/LCP53C3dyTyKLh8zhnB0gnKTPe+hyx17MB/pls8l5YJn9Ny xepakt1Apxtf433XLrCBPq7YBkN7VNZ0sWa8u+0surtxCfe+k7AETp3o9YcO8hmCFOsCX2F 32hP0OFqst9SEadem/FgQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:COPLqbwuWeI=:EsNXK7M78eh5UwuYrLFAaA rcjZk36znswukN88N8SvCQxQfFlIoTy5MfbEKB6pTnkNsnWtTU7H3k4d0YeF1eExlrbwxoyma Qc2Y8j54AdI53hZoPDQECM11yhNZCYnNPvQRy7kIrLXEUfjY6ipuOanNu8WL8d+2+aw2u5oBA UIrjbM917EDYSymI2If0uHKL1oSyHCQAzsxsPj4qSnLeS8fIm57pk7gFnmCZbp5X9YlrD5b4a ByxLru6PsXOd1vKZlEabEoHJBpIVT+yFY2CkPcm1FM5b0XM/jOgACGfKMbsqxFF0jXAOeTVhi xJEM/yU9Y744wHl+alZuaplVlH/q9XiDc2RfFmTJhuqgPes+LUa7nJqMc8xOiNR78uHOrgORG D66pbyNsAeGpG3CL8F4vXRKq1ZOiuYDTntAVyTpoZKZmserKnhzI7hxtXbFSZrivtY2XDDKzJ xIYWs/JUKY4MKJ1xO1Qo8q7lBE+Vpp6Qq/JgIQtuJKbrkPffsXuVlGzHsYLOho/H/j5szkJAA lN1Tgu88LDPtjDDIEd6losUI2QB/ksJE/HTfgDAHX47DI+ypTQknA+xLrugeBJY9whgfoJHyq /pN0Z3Iaog5ghe+Uj6AqAXsy/q0p2cnDxYZUZbzVy59B94lzVD6z/3e087pL/F0vzTp0mMd/s oHZ8y5yy18ieq93kJ4Xh52M1C49yrhHCr81eVG3ilP9mdMvraStFIh0byLsDZCFuhpZBsrdTX zTZsbfrHomWBe8k23PABTs2DSS145JTwOME/mOskN4e38I2Czn1AieyKBmkv4n6sM/SAymLQU jDlDtZ2KKV6Zlj0shtlH2sw/5SPCAqtEtlpPVUOx74+JmuUJyALcdesZQRfe5k/w6qisiGUbC mxgmPYpg3fA7M81QoG2/x7fmR2i2wh+LuY466BDaw6dLLRYVCHoAR0HZ7GPIiZyF3q8bd7/Qv 3Su4F6QHyorPgcdalL9ZNdV4H4kZTse9EFgDs+gz+eqzAxGkcnP6ETcwBGSCh9zqjaawRhSYT IGH5keN5vCqDHViWhrgABLAPoFgiV1YIpJLZ5BwCZtT8gvW+g3yGIixLdp/h9uuA4G9i7dqTB qP4Z3orwINAiec= Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 06:40:25 -0000 Am 26.01.2022 um 23:52 schrieb Jay Daley: > ... >> That was an anti-goal of the 779* design work, which intended to have t= he xml capture the semantics of the document, and not provide layout instr= uctions. If we do as you suggest, that's a big shift in requirements on th= e vocabulary, and pushes for much more frequent vocabulary version changes= does it not? > > We have features such as the newline attribute in the
element that = appear to be layout only and Carsten has listed some others below. That is true, but we really tried to minimize the number of knobs. *If* we want to provide some control over table styling, a single binary switch won't be that helpful. Note that we had many more in V2. >> There will also be (and have been) arguments about including _anything_= in the vocabulary that would influence the behavior of only one of the re= nderers. > > We already have that with the type=3D"svg" attribute of the el= ement, which is arguably has a much bigger impact than a table border. I don't think this falls into the same category. >> On 27/01/2022, at 11:41 AM, Carsten Bormann wrote: >> >> On 26. Jan 2022, at 22:38, Jay Daley wrote: >>> >>> Personally speaking, I agree with Miek that all formatting should be c= ontrolled 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. At least we shouldn't get us into a situation where there's extra metadata needed to create the RFC TXT versions (thus all of these should be the same). >... >> >> The fact that, without Henrik, we have grammar ossification, means that= we probably can=E2=80=99t fix anything before we get a v3.1. > > We have the XML and Style Guide Change Management Team https://mailarchi= ve.ietf.org/arch/browse/xml-sg-cmt/ > ... It would be awesome if the visibility of this would be greater. I really would like to be able to at least *subscribe* to this mailing list so that I see what's currently discussed. Just in this month I see a re-opening of an issue () which was supposed to be closed with consensus many months ago, and a discussion about referenceGroup titles that's related to a vocabulary ticket I opened over five years ago. Best regards, Julian From nobody Thu Jan 27 03:19:08 2022 Return-Path: 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 7A1493A0AD0 for ; Thu, 27 Jan 2022 03:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20210112.gappssmtp.com 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 ARiokWczny56 for ; Thu, 27 Jan 2022 03:19:04 -0800 (PST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9DE3A0ACC for ; Thu, 27 Jan 2022 03:19:03 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id ah7so5095700ejc.4 for ; Thu, 27 Jan 2022 03:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20210112.gappssmtp.com; s=20210112; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition; bh=VvUv1ak6zQdhU3ofFb3BOy7JDS/Jj3r8b8mrwFvCLvY=; b=NbyKXPjZCFbZlCJvmJdyDkOex2aHoADcdZdhObHWPaY5a4jdzf7frUbmcrVNBUPGjq dqsZOr9jAdK6Y01p9HMc3sUIRKTA3v1mIDQYHFBpuEN2CrjqGzohg5sJTbJX98nUiKB/ VrVvRXNby+ZSIsOpNS9fYk6eZwLqMmzALEQP8xV1mHMS98SuUmt7qNPGlXOqsiH6YZ4+ SPx6hlARk/cmcnKqxoR02HCscjs50hRO2dbkMPwf4wWr8eA8yn+zdBbmL8+Hr4/cKfH/ eW2xRk8WGBhVfwkGy0kt7fLKxxCdsfYMQnDlFFGYHano0v4X+JAb+5ylUOhWbk/xCw64 rC+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition; bh=VvUv1ak6zQdhU3ofFb3BOy7JDS/Jj3r8b8mrwFvCLvY=; b=BzeglWnbDh+DTEWhfWVsHpMkpALqc2j3rQkmTROxlqcxpmJi6h8CXPElS0tijTamL3 8CcReXbQo+ns25eqRfjbUGwjGP/3rXKQ2quiLXKw8Zn2/4XqNGPjcqwndg/4KjpmC6XS +fzVG7XRAq25Tn93QQ7xHBIP3BXg+HKLbxeuybRjosNGo19ghUpql83c/Hho2fXbCbtL T2ucmgw6gS4R8V78YlQ0sCXDDNRIozOtsTWbZODX1al1WCs/jaO3wdlTCRAEIuyFWNiv 02+z+E6Z99mL+LaeNaGy/10/zrmH0OGv4yhpOwM7vMoWrvEWkVHpZjVJsPSR+o4OJn4o uUPA== X-Gm-Message-State: AOAM532xqgmi5qIL7dAjPnOdRUj4BDSHiIszIiPsFaTcHvLx42oIZUkV 68JZKINmwS1YlLS8pvPlldJmJpasNCGbHA== X-Google-Smtp-Source: ABdhPJz6/s9YohSoaXguuVwVPc0uY3X703i3K2+jhKw3cVkSkRND5o6H9Z9H/lKjcxzM9tgYmgCL9g== X-Received: by 2002:a17:907:96a7:: with SMTP id hd39mr2613665ejc.130.1643282341272; Thu, 27 Jan 2022 03:19:01 -0800 (PST) Received: from miek.nl (dhcp-077-251-206-012.chello.nl. [77.251.206.12]) by smtp.gmail.com with ESMTPSA id jt17sm8570036ejb.161.2022.01.27.03.18.59 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Jan 2022 03:19:00 -0800 (PST) Date: Thu, 27 Jan 2022 12:18:58 +0100 From: Miek Gieben To: XML2RFC Dev Message-ID: <20220127111858.GA12488@miek.nl> Mail-Followup-To: XML2RFC Dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Archived-At: Subject: [xml2rfc-dev] xml2rfc flags nit 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 11:19:07 -0000 Hi all, I can't file bug in trac anymore, so i'll (ab)use this list. The option's help text for xml2rfc isn't up to date anymore: --text outputs formatted text to file, with proper page breaks this doesn't actually add page breaks, or maybe only for v2 input? (seen w/ latest xml2rfc 3.12) /Miek -- Miek Gieben From nobody Thu Jan 27 03:33:51 2022 Return-Path: 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 0242B3A0C38 for ; Thu, 27 Jan 2022 03:33:49 -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 ohDzHGluA3j8 for ; Thu, 27 Jan 2022 03:33:44 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::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 9C6F33A0C37 for ; Thu, 27 Jan 2022 03:33:44 -0800 (PST) Received: from [192.168.217.118] (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 4Jkz4M6kpgzDCgl; Thu, 27 Jan 2022 12:33:39 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <20220127111858.GA12488@miek.nl> Date: Thu, 27 Jan 2022 12:33:39 +0100 Cc: XML2RFC Dev X-Mao-Original-Outgoing-Id: 664976019.632232-9cf6afab0d51fe393fcbd020ac28b086 Content-Transfer-Encoding: quoted-printable Message-Id: <69FD6063-872C-41BC-AA8D-5FE567AEA434@tzi.org> References: <20220127111858.GA12488@miek.nl> To: Miek Gieben X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [xml2rfc-dev] xml2rfc flags nit 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 11:33:49 -0000 On 2022-01-27, at 12:18, Miek Gieben wrote: >=20 > Hi all, >=20 > I can't file bug in trac anymore, so i'll (ab)use this list. The = option's help text for > xml2rfc isn't up to date anymore: >=20 > --text outputs formatted text to file, with proper = page breaks >=20 > this doesn't actually add page breaks, or maybe only for v2 input? It does for Internet-Drafts. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jan 28 11:22:59 2022 Return-Path: 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 935583A0BF6 for ; Fri, 28 Jan 2022 11:22:57 -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 yMFoobwpQJ2D for ; Fri, 28 Jan 2022 11:22:51 -0800 (PST) Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16C63A0BEC for ; Fri, 28 Jan 2022 11:22:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 05F35425A344 for ; Fri, 28 Jan 2022 11:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gjDuUr0Hy5M for ; Fri, 28 Jan 2022 11:22:50 -0800 (PST) Received: from [192.168.4.33] (c-24-17-19-210.hsd1.wa.comcast.net [24.17.19.210]) by c8a.amsl.com (Postfix) with ESMTPSA id E1D95424B434 for ; Fri, 28 Jan 2022 11:22:50 -0800 (PST) From: Alice Russo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 28 Jan 2022 11:22:49 -0800 References: <33F0F5FB-5CBC-4D6D-BFB7-18AC9798C720@ietf.org> <997C8D93-EF22-42D3-A0A4-9C04EDAEF464@tzi.org> <1ee39a65-68e7-6388-fa6d-6364ff546751@nostrum.com> To: xml2rfc-dev@ietf.org In-Reply-To: <1ee39a65-68e7-6388-fa6d-6364ff546751@nostrum.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 19:22:58 -0000 > On Jan 26, 2022, at 2:48 PM, Robert Sparks = wrote: >=20 >> Somebody wanted the =E2=80=94table-borders feature, or it wouldn=E2=80=99= t have been implemented. >=20 > The RPC asked Henrik to implement it as an experiment for a document, = and it ended up not being used. To clarify, I submitted this ticket = (https://trac.ietf.org/trac/xml2rfc/ticket/527), and -- in addition to = the corresponding fix -- the table-borders option was created. IIRC, the = RPC did not ask for the feature.=20 As noted, it has never been used for producing an RFC. Thanks, Alice= From nobody Fri Jan 28 11:38:54 2022 Return-Path: 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 6BA1C3A0E17 for ; Fri, 28 Jan 2022 11:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.793 X-Spam-Level: X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com 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 pH6XLLzIc11v for ; Fri, 28 Jan 2022 11:38:49 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7337B3A0E13 for ; Fri, 28 Jan 2022 11:38:49 -0800 (PST) Received: from [192.168.1.114] ([47.186.48.51]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 20SJcj2t056060 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 28 Jan 2022 13:38:46 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1643398726; bh=9hrBftRFvNN46BOLkBSsyDYABoWHLL60Y6QWI5ml8GE=; h=Date:Subject:To:References:From:In-Reply-To; b=tLxAp0uq5JPNEx6RpwcPzfNo2LwMJumzDt8B6Hufm5ULBUW6QiNc46iJ9StqEZ+m0 M6Lgsm4hoq9AQFACi5/qayoX/AxsugqF0/t1VfTuu6Y+nfZkRypR8mUQN57FTpcddb gJU2yhgXPq3Znt4p8bImrDMWAkIY0X8InrFzVu7o= X-Authentication-Warning: raven.nostrum.com: Host [47.186.48.51] claimed to be [192.168.1.114] Message-ID: Date: Fri, 28 Jan 2022 13:38:40 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US To: Alice Russo , xml2rfc-dev@ietf.org References: <33F0F5FB-5CBC-4D6D-BFB7-18AC9798C720@ietf.org> <997C8D93-EF22-42D3-A0A4-9C04EDAEF464@tzi.org> <1ee39a65-68e7-6388-fa6d-6364ff546751@nostrum.com> From: Robert Sparks In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 19:38:54 -0000 On 1/28/22 1:22 PM, Alice Russo wrote: >> On Jan 26, 2022, at 2:48 PM, Robert Sparks wrote: >> >>> Somebody wanted the —table-borders feature, or it wouldn’t have been implemented. >> The RPC asked Henrik to implement it as an experiment for a document, and it ended up not being used. > To clarify, I submitted this ticket (https://trac.ietf.org/trac/xml2rfc/ticket/527), and -- in addition to the corresponding fix -- the table-borders option was created. IIRC, the RPC did not ask for the feature. Thanks for the clarification and apologies for my misrepresentation. > > As noted, it has never been used for producing an RFC. > > Thanks, > Alice > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev