Re: [docbook-apps] Using olinks in bibliography collection with processor's parameters with relative paths

[=?utf-8?q?K=C5=99i=C5=A1tof_=C5=BDelechovski?= <giecrilj@stegny.2a.pl>]

Dnia niedziela, 11 września 2011 o 02:04:30 Giuseppe Monticelli napisał(a):
> Good morning,
> 
> I'm experiencing a strange issue using 'bibliography.collection'
> together with 'target.database.document' and relative paths with this
> configuration:
> 
> - DocBook 5.0
> - DocBook XSL ns 1.76.1
> - xsltproc (libxml 20632, libxslt 10124, libexslt 813)
> 

[…]

> This technique works perfectly ONLY when the
> bibliography-collection.xml document is in IN THE SAME folder as the
> XML documents representing the chapters of each guide.
> 
> The problems arise when I move the bibliography-collection.xml
> document a folder above, in order to share it with all the guides,
> avoiding to duplicate (triplicate) it in every folder containing the
> chapters of each guide:
> 

[…]

>    warning: failed to load external entity
> "../../../tools/database-files/nightly/olinkdb.xml" <<<<<<<<<<<<<<<
> (!)
>    Olink error: could not open target database
> '../../tools/database-files/nightly/olinkdb.xml'. <<<<<<<<<<<<<<<
>    Error: unresolved olink: targetdoc/targetptr = 'funambol-developers-guide/'.

This problem is common to all hypertext technologies, not only DocBook: namely, how do I declare an entity to be global to the current project, without hardcoding the path to the project, so that the links continues to work if the project is logically moved elsewhere?

So far, the only solution I can think of is using virtual hosts or at least server-side redirections.  This, however, requires a global consistent project namespace implemented on the server.  It is not particularly hard but it does involve some maintenance burden.

[rant]
Note that server-side redirections are hard on Microsoft Windows up to Vista unless you refer to a true server on top of it.  There is a cryptic feature in NTFS called "file system reparse points" but there is no UI for creating or manipulating them, so it is easier to just keep things in predictable places, no matter how cumbersome and unwieldy the standard paths to those places are (except that they may also be different on different machines).  Microsoft Windows even includes a special API to find those paths but you would need to resolve them for xsltproc using a separate script since xsltproc does not support this API.
[/rant]

Cheers,
Chris