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

Julian Reschke julian.reschke at greenbytes.de
Tue Mar 1 09:19:51 PST 2016

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 

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

More information about the rfc-interest mailing list