OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[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 <bobs@sagehill.net> 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

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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]