Re: [xml2rfc-dev] https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-3.1.20
Henrik Levkowetz <henrik@levkowetz.com> Tue, 29 October 2019 20:52 UTC
Return-Path: <henrik@levkowetz.com>
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 93B14120125 for <xml2rfc-dev@ietfa.amsl.com>; Tue, 29 Oct 2019 13:52:29 -0700 (PDT)
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 XEdwrpHFe9ao for <xml2rfc-dev@ietfa.amsl.com>; Tue, 29 Oct 2019 13:52:27 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B778B12006D for <xml2rfc-dev@ietf.org>; Tue, 29 Oct 2019 13:52:27 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:63601 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1iPYTa-0002mv-Fl; Tue, 29 Oct 2019 13:52:27 -0700
To: Heather Flanagan <rse@rfc-editor.org>, Julian Reschke <julian.reschke@gmx.de>
References: <dd955428-7129-c0e9-4064-ef963ada90c7@gmx.de> <159956F3-1DDA-436E-8565-689F4EA74609@rfc-editor.org> <6b631129-546a-0935-aeca-0ad31db47d62@gmx.de> <E98A6936-406B-4D65-A077-E23989CCA6B2@rfc-editor.org>
Cc: XML Developer List <xml2rfc-dev@ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <669a5171-e8ea-5733-5f85-a6b6226dcc71@levkowetz.com>
Date: Tue, 29 Oct 2019 21:52:18 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <E98A6936-406B-4D65-A077-E23989CCA6B2@rfc-editor.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="rDwDPndN9ndaTrPUcVqkl0hCvqIVH6Gsd"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de, rse@rfc-editor.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/BAw03zsLvYbbzRo7DuhB-jOiUAk>
Subject: Re: [xml2rfc-dev] https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-3.1.20
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: Tue, 29 Oct 2019 20:52:30 -0000
On 2019-10-29 19:30, Heather Flanagan wrote: > > >> On Oct 29, 2019, at 11:21 AM, Julian Reschke <julian.reschke@gmx.de> wrote: >> >> On 29.10.2019 19:13, Heather Flanagan wrote: >>> >>> >>>> On Oct 29, 2019, at 11:09 AM, Julian Reschke <julian.reschke@gmx.de> wrote: >>>> >>>> ...see also >>>> <https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/pull/107>, which >>>> I believe is misguided. >>>> >>>> >>>>> 3.1.20. In Section 2.46.2, "numbered" Attribute >>>>> >>>>> The text indicates that only top-level sections may have >>>>> numbered="false", and that a section with numbered="false" may not >>>>> have a child section with numbered="true". But that leaves no value >>>>> that is valid for child sections of an unnumbered section: They >>>>> cannot have numbered="false", since they are not top-level sections, >>>>> and they cannot have numbered="true", since the parent has >>>>> numbered="false". >>>> >>>> That is correct, but very easy to fix by saying that numbering is >>>> inherited from the parent section. >>>> >>>>> Additionally, the prohibition against child sections having >>>>> numbered="false" removes the option of truncating the ToC listing for >>>>> some child sections; without providing a good explanation for this >>>>> limitation, it seems arbitrary and counter-intuitive to disallow this >>>>> feature. >>>> >>>> That doesn't make any sense - the presence in the ToC does not depend on >>>> numbering at all. To control the ToC, we already have >>>> <https://greenbytes.de/tech/webdav/rfc7991.html#element.section.attribute.toc>. >>>> >>>>> Proposal: Permit sections which are not top-level sections to have >>>>> numbered="false". >>>>> >>>>> Implementation: In The current version of xml2rfc, child sections >>>>> may have numbered="false". >>>> >>>> Limiting this to top-level sections was very intentional; the reasons >>>> given above are IMHO not sufficient at all for this change. >>>> >>>> Heather, by any means, please undo this change for now. >>>> >>>> >>> >>> I don’t think having numbered child sections in an otherwise unnumbered section (especially if they are inheriting a phantom number from the unnumbered section” is a good idea at all. Do you have better language that I can use to state that is prohibited? >> >> Just say that descendant sections of unnumbered sections are unnumbered >> by definition (and that it would be an error to set numbered back to true). > > Great, that gets to what I want. Say you have two sibling sections with numbered="false". If you decide you want to rearrange these, so you move one of them into the other, then suddenly if having numbered="false" in a child section is prohibited, your XML becomes invalid. I think that's unfriendly and completely unnecessary. Regards, Henrik >> >> Asking authors to repeat themselves when the intent is totally clear >> just doesn't make any sense. > > Which wasn’t my intent, but I can see how you got there. > >> >> FWIW, I'm also opposed to expanding control to subsections for now (and >> I see that you didn't adopt that part of the proposal yet). Before we do >> that, we should have a clear use case. > > Right now, I’m in the middle of trying to figure out how to capture the reality of <seriesInfo> and make appropriate changes. After that, it will be <sourcecode> and then (if my brain hasn’t melted) “keepWithNext”. > > -Heather > > > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev >
- [xml2rfc-dev] https://tools.ietf.org/html/draft-l… Julian Reschke
- Re: [xml2rfc-dev] https://tools.ietf.org/html/dra… Heather Flanagan
- Re: [xml2rfc-dev] https://tools.ietf.org/html/dra… Julian Reschke
- Re: [xml2rfc-dev] https://tools.ietf.org/html/dra… Heather Flanagan
- Re: [xml2rfc-dev] https://tools.ietf.org/html/dra… Henrik Levkowetz
- Re: [xml2rfc-dev] https://tools.ietf.org/html/dra… Henrik Levkowetz
- Re: [xml2rfc-dev] https://tools.ietf.org/html/dra… Julian Reschke
- Re: [xml2rfc-dev] https://tools.ietf.org/html/dra… Julian Reschke
- Re: [xml2rfc-dev] https://tools.ietf.org/html/dra… Julian Reschke
- [xml2rfc-dev] v3 <seriesInfo> vs IMPNOTES vs cano… Julian Reschke
- [xml2rfc-dev] XML evolution (Re: v3 <seriesInfo> … Carsten Bormann
- Re: [xml2rfc-dev] v3 <seriesInfo> vs IMPNOTES vs … Heather Flanagan
- Re: [xml2rfc-dev] [Ext] v3 <seriesInfo> vs IMPNOT… Paul Hoffman
- Re: [xml2rfc-dev] [Ext] v3 <seriesInfo> vs IMPNOT… John R Levine
- Re: [xml2rfc-dev] v3 <seriesInfo> vs IMPNOTES vs … Julian Reschke
- Re: [xml2rfc-dev] XML evolution (Re: v3 <seriesIn… Julian Reschke