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 <indexterm/> cannot be a direct child of an <abstract/>, so I moved it
inside of the <para/>
neither can <command/> be the direct children of a <sect1/>, so I moved them,
each inside a <para/>
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
DocBook 4.x appears to be fairly picky about order in <author/> elements and
the document will not validate without the order being correct. Fixed.
Also, in the <revhistory/>, there were plenty of places where multiple
<revremark/> elements needed to be wrapped in a <revdescription/> along with a
bunch of <remark/> elements instead.
first, this is not XSL and in DocBook 4.x, these extra namespaces confuse the
processing toolchain (may be different in DocBook 5.x); next, xmllint refuses
to validate the document because of the order of elements in, for example the
<author/> elements and the <affiliation/> elements; just flipping these in
most cases did the trick
added a bunch of corrections for <itemizedlist/> <listitem/> and <para/>
nesting to match the DocBook content model more strictly; this allows full
validation of the document
the external general entities (files) which were getting pulled in already
contained a <programlisting/> element; this XML element was not necessary, but
the lack of an <areaspec/> inside the <programlistingco/> was giving xmllint
fits.
apparently, DocBook is quite picky about the order of children elements within
the <affiliation/> element; so rearranged; and also only one of <revremark/>
or <revdescription/> is (technically) allowed in a <revision/>, so I chose to
convert the <revremark/> elements to <remark/> and drop them inside of a
<revdescription/>, which allows much richer expression of content
I don't know how this document ever validated before. There were countless
locations where there were extra </itemize> closing tags and tons of missing
<itemize> opening tags.
I tried not to do any violence to the nesting, but it was very difficult to
understand, given the ambiguity. The document now validates and can be built.
Martin A. Brown