--p4qYPpj5QlsIQJ0K
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2005.12.16 18:37:49 +0100, Klaus Heinz wrote:
| I wrote:
|=20
|  [ Problem: using the same relative path in an "url" attribute in differe=
nt
|    documents ]
|=20
| > 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#LinkBet=
weenDocs)
| > 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.
|=20
| 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.
|=20
| 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.

They are _target_ files. Do you store .o in cvs too ? :-) (yeah, I
know it's a bit different).
I think they should stay out of the htdocs tree (as is autolayout.xml)

|=20
| - 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.

Fixing our styleshees to include docbook.xsl solves the problem ?

| - 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.

*sigh* I wouldn't want to take this route (again)...

|=20
| > Instead of using
| >   <ulink url=3D"../../Bla/foo.html#some.anchor.id" />
| >=20
| > we would then have
| >=20
| >   <olink targetdoc=3D"doc.foo.id" targetptr=3D"some.anchor.id" />
|=20
| To me, the existing handling of <olink> in DocBook website seems not usab=
le
| 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:
|=20
| Example: a news item points to "/MailingLists/#source-changes", two
| different documents need links like this
|   "../MailingLists/#source-changes"
|   "../../MailingLists/#source-changes"
|=20
| I think we could scrap the website stuff for <olink> and use our own.
|   <olink type=3D"pkgsrc" targetdoc=3D"/MailingLists" targetptr=3D"#source=
-changes" />
|=20
| "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/^\//.\//}.

This makes sense. Again, the big issue here is to tell people how to
use it. Think about people who are not following this thread and never will.

		-- Rui Paulo

--p4qYPpj5QlsIQJ0K
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFDo1fIZPqyxs9FH4QRAkbaAKCzzilfEz60iNFlBkZU92QkO1FHHwCgjye4
fxD/7P6wy+ToK+jv3p9KDzM=
=ha+a
-----END PGP SIGNATURE-----

--p4qYPpj5QlsIQJ0K--