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

Julian Reschke julian.reschke at gmx.de
Mon Feb 29 21:57:02 PST 2016


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.

Best regards, Julian



More information about the rfc-interest mailing list