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

On 2005.12.10 20:53:24 +0100, Klaus Heinz wrote:
| Hi,
|=20
| I would like to pick up a thread from earlier this year
|=20
|   "better integration of news pages for NetBSD and pkgsrc"
|   http://thread.gmane.org/gmane.os.netbsd.documentation/969
|=20
|   [ XML-file with news entries, re-usable in different documents ]
|=20
| In this case (and in several others, probably) we need a list of
| objects which can be used in several documents.
| Hiroki Sato already provided some patches to implement this for
| htdocs/Changes/*.
|=20
| Looking at this again, I found we still have at least one problem with
| this approach: Today we use <ulink> for cross references / links to
| other documents which is fine for absolute URLs. This can fail miserably
| if we have relative paths for "url" attributes in an <ulink> element=20
| and then include such an element in more than one document at different
| levels in the directory hierarchy.
|=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#LinkBetwe=
enDocs)
| 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
| 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
| which should be resolved to different "href" attribute values in the
| resulting HTML (or whatever is used in PDF, when we come to that point),=
=20
|=20
| Comments?

I think it's fine to use what you suggest. But how can we enforce this
? While we are there, how can we enforce the CALS table model ?

		-- Rui Paulo

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

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

iD8DBQFDndBMZPqyxs9FH4QRAsQYAKCavq2CqycC1yyaP+KAchBSZVeLrQCdHWwi
7EqXNOQXrkraPOuPawrnhnw=
=FIyy
-----END PGP SIGNATURE-----

--Q59ABw34pTSIagmi--