added a DocBook 5.0 declaration and, after failing validation with jing,
changed the anchor location to be inside the <firstname/> element.
Validates now!
(and restoring commit 78ec6080e6 which
suppresses the dbhtml PI for document naming)
Assembly-HOWTO.xml was written as a DocBook 5.0 document, however it sported a
declaration of a DocBook XML 4.5 document. This confused me and I changed all
of the <xlink:href/> elements to <ulink/> elements.
reverts commit 13943cb7fb
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
the entire set of directories here had been checked in (in 2005) under
NCURSES-Programming-HOWTO; and has since been moved to a subdirectory,
NCURSES-Programming-HOWTO/resources
this is cruft and does not need to be here (there are even newer files in the
NCURSES-Programming-HOWTO/resources/ncurses_programs directory
Several <xref/> elements used the endterm attribute, which takes the entire
content contained in the element as replacement. Because the endterm was
also, for example, a <section/>, the replaced text was a gigantic (multi-page)
link with the whole section included. Unintended, I'm sure.