OpenPOWER Library

 1.5.4. FO validation failures

FO (formatting objects) validation failures are a slight bit more difficult to identify and require more effort to correct. A sample appears as follows:

  "{}block" is not a valid child of "fo:list-block"!
  (See position 70:-1): null:70:-1: "{}block" is not 
  a valid   child of "fo:list-block"! (See position 70:-1)
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 35.900s
[INFO] Finished at: Sat Mar 19 15:54:34 CDT 2016
[INFO] Final Memory: 107M/256M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal (generate-webhelp) on project hwarch-caia-spec: Failed to transform to PDF: "{}block" is not a valid child of "fo:list-block"! (See position 70:-1): null:70:-1: "{}block" is not a valid child of "fo:list-block"! (See position 70:-1) -> [Help 1]

The "" text indicates that this error was during FO validation. The key pieces of information are as follows:

  1. The error type is indicated in the text following the exception indictor. In our case, the error statement is: "{}block" is not a valid child of "fo:list-block"!. This error clearly has something to do with the nesting of a "fo:block" statement in a "fo:list-block" statement.

  2. The location of the validation error is given in the statement "See position 70:-1". These two values are the line number and character number of the error. So, our sample error occurs on line 70, but the character number of -1 is an indication that the line is too long to effectively point.

What this information fails to detail is which file has the problem. To find the particular offending file, one must understand the Docbook build process. This process begins by collecting all XML into a working copy of the main book file. The build failure error in Section 1.5.2, “Docbook validation errors” includes a reference to this file which will be found in the .../target/ directory. It generally has the same name as the main book file of the document, which if copied from the Documentation Development Guide project, will be bk_main.xml. When in doubt about this file name, you will find it in the <includes> tag in the pom.xml file.

Once all information has been pulled into the working XML file, the XML statements are transformed into FO statements in preparation for building the PDF. This step generates a .fo file which can be found in the .../target/docbkx/autopdf/ directory and typically has the same base file name as the target PDF file. Again, the pom.xml file will clarify this name with the <pdfFilenameBase> variable.

If one locates and opens the .fo file, it becomes obvious that it was intended as a working file and is not readily readable. Therefore, the first step to understanding this error is to make the FO file more readable. The xmllint tool can be used to create a more readable FO file. Assuming you have been working in the document directory, the follow steps can be used to produce a more readable XML file:

$ cd target/docbkx/autopdf
$ xmllint --nonet --noent --nowarning --version --timing --format -o outfile infile
xmllint: using libxml version 20901
   compiled with: Threads Tree Output Push Reader Patterns Writer SAXv1 FTP HTTP DTDValid HTML Legacy C14N Catalog XPath XPointer XInclude Iconv ISO8859X Unicode Regexps Automata Expr Schemas Schematron Modules Debug Zlib Lzma 
Parsing took 63 ms
Saving took 39 ms
Freeing took 9 ms

For your invocation of xmllint, substitute infile with the name of the Maven-generated .fo file for your new project and pick a new outfile for the new .fo file.


The xmllint utility may need to be loaded on your system. On an Ubuntu Linux system, this utility is provided in the libxml2-utils package. To locate the proper package for your system, you may need to reference Google.

Now, with a nicely formatted FO file, we can re-invoke the FO Processor (FOP) directly and achieve a more readable error. To do this, invoke fop as follows:

$ fop -fo fofile and -pdf pdffile
Rendered page #1.
Rendered page #2.
Rendered page #3.
Rendered page #4.
Rendered page #5.
Rendered page #6.
Rendered page #7.
javax.xml.transform.TransformerException: "fo:block" is not a valid child of "fo:list-block"! (See position 7830:112)

As expected, the FOP again reports an exception. However, this time the position information appears more complete. With this new information and a nicely formatted .fo file, one can find the format statements in error, find the context for the error, and then locate the correct source DocBook (XML) file. With this information, one can inspect the document source to decide if the error is bad DocBook syntax or a tooling bug. If the latter, please save the newly formatted .fo file and include it in the bug writeup.


This error generally indicates a problem with documentation tooling. If you encounter such a situation, please post to the Documentation Development mailing list at so they can assist in identifying the exact cause of the failure.

If you wish to fully understanding the error, you may require knowing more about XSL FO syntax. Many such web sites exist for this, but the XSL Formatting Objects Summary from W3C (World Wide Web Consortium) provides a good starting reference online at

loading table of contents...