This is the mail archive of the
mailing list for the DocBook project.
[docbook] RE : [docbook] Re: RE : [docbook] Simplify ToC content model
- From: Frédéric Glorieux <frederic dot glorieux at ajlsm dot com>
- To: "'Norman Walsh'" <ndw at nwalsh dot com>, <docbook at lists dot oasis-open dot org>
- Date: Tue, 29 Apr 2003 13:49:10 +0200
- Subject: [docbook] RE : [docbook] Re: RE : [docbook] Simplify ToC content model
> | Why not understanding a tocentry (a reference to a part of a
> | document), like a bibliomixed?
Let's try to find arguments.
> If you're building some external ToC (like the ToC structures in
> Website), there's no reason to stick with the simple form described
> here, you can invent your own.
Perhaps it's a bad design, but I should explain some more on our
Let's keep the problem on html site.
We use more than one type of documents linked together, and
after different experiences, it seems that the easiest solution is to
keep the exact file system hierarchy, copy all and transform what could
be (instead of external "toc", which could be docbook website, but also
ant build.xml or cocoon sitemap.xmap).
If we talk only of docbook, the root file is an index.xml, which
is a <section/>. All brother files are <section/> also, logically nested
(and rendered as in a one file export). All brother folders should have
an index.xml, which is the nested section in the upper index.xml. And so
This is expressed by the author like that
<ulink url="cr2003-01-10.xml">10 janvier 2003, lancement
du groupe de travail Monuments Historiques</ulink>
<ulink url="cr2003-01-09/index.xml">9 janvier 2003,
lancement du groupe de travail Inventaire</ulink>
A ulink is here used to be visible for xml editor or browser, but the
text in it (and other infos) will be replaced with an xsl:document().
Internally to the xsl, a valid <toc/> will be build (with dates,
abstract, and some other useful things for a sitemap menu), and
templates will be applied on it.
This internal toc model is not validated by DTD, but it seems to be nice
to keep it as valid docbbok <toc/>, especially for the next point.
> Copying the metadata around is just inviting trouble. If you're
> putting the ToC in the document, you shouldn't need to physically copy
> the data.
Problems are beginning when I want to use this pattern to link
with binary files, from which I can't easily extract datas with xsl. So
it's up to the author to give them in a docbook doc
20 février 2003, de 9h30 à 17h00 STRUCTURATION DE
Journée d'information ouverte à toute la DAPA, présentant des
réalisations déjà effectuées
avec XML, afin d'ouvrir le chantier de la modélisation patrimoniale.
I'm also using this when I open a tocentry on a file which is
not yet available.
> I haven't seen anything like that used. Generally, I'd expect the
> processing system to navigate from the tocentry to the actual content
> (that's why tocentry has a 'linkend') to get any metadata associated
> with the entry.
I'm not sure to understand @linkend, but the relative url I need is not
strictly an IDREF; and also, "it is up to the application to generate
appropriate cross reference _text_ from the element pointed to by
Linkend", but I need something more than text.
To unsubscribe, e-mail: docbook-unsubscribe at lists dot oasis-open dot org
For additional commands, e-mail: docbook-help at lists dot oasis-open dot org