Or 'How to cope with a proliferation of test results'.
Keeping track of test results was simple when xmlroff had one backend that produced one output format.
With multiple backends and multiple output formats, there's some things that xmlroff just can't do properly, some things that a particular backend can't do properly, and some things that a particular output format of a backend can't do properly. And in many cases the output will change if --compat/--nocompat is used (particularly if we get back into using the DocBook test suite).
This leads to a hierarchy of test results:
xmlroff
Cairo backend
PDF output
PostScript output
SVG output
GNOME Print backend
PDF output
PostScript output
--compat
Cairo backend
PDF output
PostScript output
SVG output
GNOME Print backend
PDF output
PostScript output
It would be simpler if the xmlroff test results were complete (i.e., they had a <testresult> element for each test) and the other test results could just have <testresult> elements for the tests where their results differed from results higher up in the hierarchy.
This implies a way to define the hierarchy, or at least a way to define the parent results of a particular set of results, and the ability of an individual test results's report to show or allow access to and modification of corresponding results "up" the hierarchy.
This does not imply being able to compare output with results from "up" the hierarchy since all test results except the backend-and-format-specific results are merely convenience measures to save having to update multiple result sets when, say, xmlroff implements a new property.
