[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Base URI for result of transformation?
Bob Stayton <email@example.com> writes: ... > I took a look at the testdocs directory, and it seems that an xml:base > wouldn't help there anyway. For example, the testdocs/tests/figure.001.xml > has a fileref="graphics/duck-small.eps", but there is no "graphics" directory > under tests. Rather, these files are meant to be processed by the Makefile > from above in the testdocs directory with a command that processes the path > "tests/figure.001.xml". The graphics directory is under testdocs, so the > relative path works there. But that's perhaps an unusual setup, and not one I > would generally recommend. At least part of the confusion has been that there wasn't a handy Makefile in docbook-testdocs-1.1. Also, the README file doesn't give any expectation of where to process the test docs. For how to use the test docs, it includes only: Process your DocBook documents with your favorite tool. I do. Another part of the confusion has been differing expections of how to use the test docs. Looking at the Makefile, it has rules to make processor-specific .fo files in the 'testdocs' directory and other rules to run specific processors on their processor-specific .fo files. For my purposes, I want to use the DocBook testdocs as just another testsuite for testing xmlroff, which means that: the testdocs distribution stays in one place and doesn't get any working or output files added to it; I don't generate .fo files; I process the test docs multiple times using different combinations of xmlroff parameters; and the output of a run goes in a directory parallel to the directory containing the results of running the xmlroff testsuite using the same parameters. I have had to make the xmlroff 'testing' module more flexible in order to handle the DocBook test docs, which on the whole is a good thing, and the original question was based on a desire to flex in the right direction. In the general case, you wouldn't want to require that all references to external files should always be resolvable, but for the purposes of reusing the test documents as a testsuite for an XSL processor, it seems to me that it would be simplest if there weren't testsuite-specific expectations about where to process the test documents. But if there are necessary testsuite-specific expections about where to process the test documents, then it would help if the expectations were documented. Regards, Tony.