I wrote:

 [ Problem: using the same relative path in an "url" attribute in different
   documents ]

> If nobody has a better idea, we may have to start using (and converting
> existing XML files to use) <olink> elements. I had a brief look at how
> <olink> works (http://www.sagehill.net/docbookxsl/Olinking.html#LinkBetweenDocs)
> and I think it needs a bit of infrastructure to determine the relative
> paths during XSLT transformation. It seems to be somewhat similar to
> the layout.xml/autolayout.xml scheme.

I found some problems while trying to use the <olink> mechanism as it
is provided by DocBook website.
For every XML document we have to create a second document
describing all the possible targets in the XML document (a "target
file"). All the target files need to be included in the global target
database (conforming to LOCALBASE/xsl/docbook/common/targetdatabase.dtd).
This target database can then be used by the stylesheets to compute the
relative links during transformation to HTML.

Problems:
- Where do we store the target files? They are clearly derived from the
  XML files so CVS should not be necessary but then everyone needs to
  update the corresponding target file in their local tree when some
  XML file in CVS changes.

- According to documentation I found, using "--string-param
  collect.xref.targets yes" with xsltproc should transform an XML file
  and create the target file in a single step. This does not work for me
  with our stylesheets in htdocs/share/xsl because the mechanism that is
  supposed to do that is located in the template for "/" in
  LOCALBASE/xsl/docbook/html/docbook.xsl and out stylesheets include
  LOCALBASE/xml/website/xsl/website-common.xsl which overrides this
  template for "/". This may be a bug in the website stylesheets.

- Looking at the available stylesheets suggested that there is a way to
  use our generated autolayout.xml to create the target database for all
  the XML files listed in layout.xml. Unfortunately this uses huge
  amounts of RAM, probably due to the problem with xsltproc we encountered
  previously.

> Instead of using
>   <ulink url="../../Bla/foo.html#some.anchor.id" />
> 
> we would then have
> 
>   <olink targetdoc="doc.foo.id" targetptr="some.anchor.id" />

To me, the existing handling of <olink> in DocBook website seems not usable
in htdocs. For the problem at hand we only need a way to
automatically determine the level where we are in the directory
hierarchy for a given document and prepend the appropriate amount of
"../.." in front of those links imported from a central file:

Example: a news item points to "/MailingLists/#source-changes", two
different documents need links like this
  "../MailingLists/#source-changes"
  "../../MailingLists/#source-changes"

I think we could scrap the website stuff for <olink> and use our own.
  <olink type="pkgsrc" targetdoc="/MailingLists" targetptr="#source-changes" />

"type" is defined as application-specific so we can handle this in our
stylesheets. Through our Makefiles we already know WEB_PREFIX and the
relative path in every directory is simply
  ${WEB_PREFIX:S/${.CURDIR}//:C/^\//.\//}.

ciao
     Klaus