XML: Single root element

Some time ago we upgraded our documentation from SGML to XML in a huge 
step. Most of the resulting files are well-formed - but not all. The 
well-formed criteria is violated by such files which contains more than 
one root element. You can locate such files with the command:

xmllint --noout *.sgml ref/*.sgml 2> >(grep Extra)

Actually this is not a serious problem. But for further XML processing 
(parsing, Docbook upgrade to version 5.x, use of an XML-editor, 
xinclude, xpath, namespaces, ... ) it is necessary - or at least very 
helpful - to change the content of every single file in a manual step to 
a *well-formed* XML file, especially with one single root element. The 
attached patch results from applying different strategies to achieve 
this aim.

Strategy 1: Move the element of the outer file where the 'calling' 
entity resides to the included file as an additional top-level element. 
Example 'legal.sgml':

Actual situation
================
postgres.sgml:
<book id="postgres">
  <title>PostgreSQL &version; Documentation</title>

  <bookinfo>  <corpauthor>The PostgreSQL Global Development 
Group</corpauthor>
   <productname>PostgreSQL</productname>
   <productnumber>&version;</productnumber>
   &legal;
  </bookinfo>
  ...


legal.sgml:
<date>2019</date>

<copyright>
  <year>1996-2019</year>
  <holder>The PostgreSQL Global Development Group</holder>
</copyright>

<legalnotice id="legalnotice">
...
</legalnotice>
-- End of File --

New situation
=============
postgres.sgml:
<book id="postgres">
  <title>PostgreSQL &version; Documentation</title>

  &legal;
  ...


legal.sgml:
<bookinfo>
  <corpauthor>The PostgreSQL Global Development Group</corpauthor>
  <productname>PostgreSQL</productname>
  <productnumber>&version;</productnumber>
  <date>2019</date>

  <copyright>
   <year>1996-2019</year>
   <holder>The PostgreSQL Global Development Group</holder>
  </copyright>

  <legalnotice id="legalnotice">
  ...
  </legalnotice>
</bookinfo>
-- End of File --

Some single files are changed but the intermediate file (respectively 
the main memory) after resolving all entities keeps unchanged. This file 
resp. main memory is the basis for all further steps like validation or 
output generation.

Strategy 2: The files of the release notes consists of many 
sect1-elements at the top level. To overcome this situation one can try 
to change sect1 to sect2, sect2 to sect3, ... and use a new sect1 
element as a cramp over the complete file. The chain of sect<n> sections 
is limited to 5 levels - and in some cases we use all of them. Therefore 
it's necessary to change the mark-up from sect<n>-elements to 
section-elements, which can be used recursively without limits.
This strategy leads to changes in the visual representation of the TOC, 
because every title-element shifts one level down. (In my opinion this 
is an improvement because a: after clicking to 'Release Notes' we 
actually have 372 items plus their sub-items. This will be reduced to 
one item per major release: 11, 10, 9.6, 9.5, ... and b: the 
acknowledgement-element is shown - as intended - per complete major 
release, not only with the very first version of a release.) Furthermore 
we have exactly one HTML file per major release for the standard HTML 
output.

Strategy 3: Split huge files into smaller files (contrib, xfunc) and/or 
shift some sections to the calling file. From the perspective of a git 
user or someone, who translates the documentation to a different 
language, this is not funny but I hope that it will be accepted.


PS_1: For tests don't forget the Make-target 'errcodes-table.sgml'
PS_2: The remaining files version.sgml, filelist.sgml and 
ref/allfiles.sgml, which contains nothing but entity definitions, will 
possibly change or get superfluous with the migration to Docbook 5.x.

Kind regards
Jürgen Purtz