8 messages in org.oasis-open.lists.docbook-appsRe: [docbook-apps] Using olinks in bi...| From | Sent On | Attachments |
|---|---|---|
| Giuseppe Monticelli | Sep 10, 2011 5:04 pm | |
| Bob Stayton | Sep 11, 2011 1:39 am | |
| Křištof Želechovski | Sep 11, 2011 2:23 am | |
| davep | Sep 11, 2011 3:29 am | |
| Giuseppe Monticelli | Sep 11, 2011 4:42 am | |
| Křištof Želechovski | Sep 11, 2011 8:46 am | |
| davep | Sep 11, 2011 9:44 am | |
| Křištof Želechovski | Sep 11, 2011 10:42 am |
| Subject: | Re: [docbook-apps] Using olinks in bibliography collection with processor's parameters with relative paths | |
|---|---|---|
| From: | Křištof Želechovski (giec...@stegny.2a.pl) | |
| Date: | Sep 11, 2011 2:23:54 am | |
| List: | org.oasis-open.lists.docbook-apps | |
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