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
>