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

[tony at att.com (HANSEN, TONY L)]

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.

	Tony