Hi there,
Just to close this thread. Here is my final comment. I followed the
guidelines from:
http://www.docbook.org/guidelines My understanding is that docbook-apps is the mailing list
appropriate for contribution outside of the docbook language itself
but directly related to application manipulating docbook.
Having said that, I am attaching an xsl script which generate
targetset structure (I believe this is the correct name) for further
olink processing. I am not attaching copyright or license since the
script is based largely on a post from the xsl-list.
The requirements for this script is that your build system (CMake in
my case) generates a list of file to be installed (see demo.xml)
<files>
<file>
<path>share/doc/Corporate/Training/BuildQtApplicationsWithCMake.pdf</path>
</file>
<file>
<path>share/doc/Corporate/Training/BuildQtApplicationsWithCMake/index.html</path>
</file>
...
I simply copy the list of string from the 'make install' rules and
then decorate them with preceding <file> and trailing </file>. This
step is build system dependant (I did it using simple cmake-string
manipulation).
Once you have this input file. Just process it with
convert_flat_tree_to_targetset_tree.xsl
$ xsltproc convert_flat_tree_to_targetset_tree.xsl demo.xml
This will produce a general olinkdb.xml file:
<targetset>
<targetsetinfo>
Description of this target database document,
which is for the examples in olink doc.
</targetsetinfo>
<sitemap>
<document targetdoc="BuildQtApplicationsWithCMake"></document>
baseuri="BuildQtApplicationsWithCMake.pdf">
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
href="BuildQtApplicationsWithCMake.olinkdb.xml"/>
<document targetdoc="BuildQtApplicationsWithCMake"></document>
baseuri="index.html">
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
href="BuildQtApplicationsWithCMake.olinkdb.xml"/>
...
If you are still reading at that point, you should have notice that
this layout imply that both the global olinkdb.xml and the individual
*.olinkdb.xml (as generated by collect.xref.targets "only") should be
located in the same directory, which means you have to specify an
appropriate targets.filename.
With this script you do not have to manually maintain neither the list
of installed document, nor the path where they are located, and you
leave that to the appropriate tool: your build system.
I am not an XSL expert, so I cannot comment on the style of this
script (portability, robustness...). I made the decision to go away
from DTD and prefer XInclude, so you may have to adapt the xsl script
if you cannot do XInclude.
Thanks for your attention,
-Mathieu
Ps: This script fails when the list of filename is not alphabetically
ordered, I used an intermedicate xsl:sort operation in my case, but
could be done at cmake level.
On Thu, Jul 8, 2010 at 7:29 PM, Bob Stayton <bobs@sagehill.net> wrote:
> Hi Mathieu,
> If this is about olinking, then it is relevant to this list. I didn't get
> that from the original mail since it didn't mention "olink", but "targetset"
> should have been a sufficient clue.
>
> I've thought about creating some kind of stylesheet to generate an olink
> targetset structure, but I've never been able to figure out what it should
> do, since everyone's requirements would be different.
>
> In your case, your XML example shows the output structure, but generating a
> targetset structure requires knowledge of the targetdoc values and the
> locations of the target data files (target.db) to be integrated into the
> targetset structure. Is that information in this XML example?
>
> I'm also not clear about what you meant when you said:
>
> "where common directory need to contains multiple files, so I cannot
> simply process one string at a time, but would need some kind of hash
> table to find out redundancies."
>
> Can you provide a bit more detail?
>
> Bob Stayton
> Sagehill Enterprises
> bobs@sagehill.net
>
>
>