OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE : [docbook] Re: RE : [docbook] Simplify ToC content model

	Thanks Norm,

> | 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
on recursively.
	This is expressed by the author like that

    <toc role="index">
                <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

                <ulink url="cr2003-02-20.doc">
                20 février 2003, de 9h30 à 17h00 STRUCTURATION DE
                <phrase role="abstract">
    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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]