[rfc-i] draft-iab-html-rfc-02: references

julian.reschke at greenbytes.de (Julian Reschke) Tue, 01 March 2016 17:19 UTC

From: julian.reschke at greenbytes.de (Julian Reschke)
Date: Tue, 1 Mar 2016 18:19:51 +0100
Subject: [rfc-i] draft-iab-html-rfc-02: references
In-Reply-To: <B8229291-E9CE-43B4-B13A-6BE8B5E09F53@vpnc.org>
References: <56D16672.4000708@gmx.de> <0EB37407-B7F1-4022-9822-6D5720D45B8C@vpnc.org> <56D1CFD8.2090909@gmx.de> <017E4EA1-75C5-4891-AC5C-D5ABD845A1D3@vpnc.org> <56D1D4C4.1090007@gmx.de> <64E8088C-4B3B-4445-B3DF-C673579EEE14@cisco.com> <0E1902D3-A929-40D3-BEF7-2064D9F5A6A5@cisco.com> <BF9113FB-DE8C-4EFC-8B74-571B8C22FACC@cisco.com> <56D52F2E.3000003@gmx.de> <51D08667-F744-4507-981C-F82100A39459@att.com> <B8229291-E9CE-43B4-B13A-6BE8B5E09F53@vpnc.org>
Message-ID: <56D5CF37.4060504@greenbytes.de>

On 2016-03-01 17:50, Paul Hoffman wrote:
> On 1 Mar 2016, at 6:12, HANSEN, TONY L wrote:
>
>> On 3/1/16, 12:57 AM, "rfc-interest on behalf of Julian Reschke"
>> <rfc-interest-bounces at rfc-editor.org on behalf of
>> julian.reschke at gmx.de> wrote:
>>
>>
>>> On 2016-02-29 23:06, Joe Hildebrand (jhildebr) wrote:
>>>> Even worse, there might be one, two, or more <references> children
>>>> of <back>.  If there is one, it's the entire References section.  If
>>>> there are two or more, the output formatter has to create a section
>>>> to contain all of the <references> sub-sections.
>>>>
>>>> One way to make this less error-prone in the output formatters would
>>>> be to make these changes:
>>>>
>>>> - v3 would add a new <referencesection> element as a child of
>>>> <back>, which can occur at most one time.  If there is a
>>>> <referencesection>, <back> must not include any <references>.
>>>> <referencesection> can contain one or more <references>, and may
>>>> have a <name>
>>>>
>>>> - if the <referencesection> does not have a <name>, the prepTool
>>>> adds one with the text "References"
>>>>
>>>> - referencesection/name gets slugified by the preptool, as all
>>>> <name> elements do
>>>>
>>>> - if the prepTool sees more than one <references> child of <back>,
>>>> it creates a new <referencesection> element (if one doesn't exist),
>>>> and moves the existing <references> children of <back> to instead be
>>>> children of <referencesection>
>>>>
>>>> - the prepTool would assign part numbers to <referencesection> and
>>>> <references> starting with the next-highest number from those used
>>>> in middle/section/@pn, and treating referencesection/references as a
>>>> sub-section
>>>>
>>>> - if there is only a single <references> child of <back>, it remains
>>>> unchanged by the preptool, other than getting a @pn
>>>
>>> That sounds like a really complicate plan for fixing something that the
>>> existing tools have handled just fine in the past. I'd just stick with
>>> the status quo.
>>
>> I'm with Julian on this one.
>
> ...and yet we still have no text specifying what "the existing tools"
> do. In trying to determine what "the existing tools" do, the set of
> steps seem to have a lot of guessing in them. If that's wrong, it would
> be good to have some text that shows what happens.

If there's only one <references> element: include that as top-level section.

Otherwise: wrap all <references> into a top-level section called 
"References".

This is interoperably implemented in three implementations, so I don't 
think there's problem here, except that we never wrote down what's 
supposed to happen.

Best regards, Julian