XML Parse error on Local Build

[Geert Janssens]

Op dinsdag 6 december 2016 17:05:37 CET schreef David T. via gnucash-devel:
> Hi,
> 
> I am trying to finish a first pass at a new Glossary for the Guide. My
> changes are focused in a new file (gnc-glossary.xml) and in
> gnucash-guide.xml. In the latter, I have added two lines to incorporate the
> new file into the guide.
> 
> I have reached the point of running the commands:
> 
> xmllint --valid --noout gnucash-guide.xml
> xsltproc -o ../../../output_html/guide/ ../../xsl/general-customization.xsl
> gnucash-guide.xml
> 
> These are prescribed by the Wiki page. 

A side note, more targeted at Chris who's done an excellent job so far to keep 
the Documentation Update wiki page up to date:
I haven't fully read that page in a long time, so this never struck me before:

I wonder why you explicitly explain to use xmllint and xsltproc ?
Both commands are incorporated in the makefile system for the documentation.

So my typical flow (after a git clone/checkout/pull whatever) is
- in the gnucash-docs directory run "./autogen.sh"
- then make a build directory to keep the build documentation out of the 
source tree for cleanliness. Let's call that directory "build" for this 
example. Typically this can be done using
"mkdir build"
- Then from within the build directory call configure. Assuming build is a 
direct subdirectory of gnucash-docs, do
  cd build
  ../configure
- This will recreate the gnucash-docs directory structure under build. But not 
the files. Instead you will find a Makefile in most directories. From now on 
you can choose at which level you wish to run commands. Either for all of the 
documentation, or only for the guide or only for one specific language of the 
guide. Just cd into the proper directory. For the options above these would be 
respectively: build, build/guide and build/guide/<lang>.
- The command to run xmllint is
make check
- The command to generate the html documentation is
make html

Did you have a particular reason not to use these ? The documentation will let 
you use these anyway in a later step  to "test on linux", so I figure you 
might as well just stick with them for the earlier steps as well. That way 
there's only one set of commands to remember.

Regards,

Geert