This version should not be present here.....if the LFS folk wish to contribute
it, then, it should go right on top of the older version. I did not want to
make that choice for them, but having the duplicate here is also not good, so
I'm removing it.
It is not valid to have <indexterm/> elements directly as a child of a
<varlistentry/>, so I have moved them inside the <listitem/>. I tried putting
them inbetween <varlistentry/> elements (no good).
It is not valid to have <indexterm/> elements directly as a child of a
<varlistentry/>, so I have moved them inside the <listitem/>. I tried putting
them inbetween <varlistentry/> elements (no good).
It is not valid to have <indexterm/> elements directly as a child of a
<varlistentry/>, so I have moved them inside the <listitem/>. I tried putting
them inbetween <varlistentry/> elements (no good).
there were two locations where CDATA was outside of an enclosing </para> or
inside another element that could not contain it (according to the DocBook XML
element nesting model).
An <abstract/> element can contain a <para/>, which can contain an
<itemizedlist/>, but the <itemizedlist/> may not be a direct child of an
<abstract/>.
there was a mismatch between the root element and the doctype declaration;
assuming that the root element is correct, synchronizing these two changes
fixed the validation problems
the doctype declaration had conflicting entries; the public identifier said
4.1.2 and the system identifier said 4.0; I would not have noticed this,
except that xmllint was complaining about the <author/> element containing an
<email/> (invalid!)
this was easily resolved by changing the version of this document to be a
DocBook XML 4.2 document
Move the <?dbhtml filename="glossary"?> to its correct location after the
opening <glossary> tag; otherwise the index.html file gets named
glossary.html (oops!).