[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 usage. 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"> <tocpart> <tocentry> <ulink url="cr2003-01-10.xml">10 janvier 2003, lancement du groupe de travail Monuments Historiques</ulink> </tocentry> <tocentry> <ulink url="cr2003-01-09/index.xml">9 janvier 2003, lancement du groupe de travail Inventaire</ulink> </tocentry> </tocpart> </toc> 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 <tocentry> <ulink url="cr2003-02-20.doc"> 20 février 2003, de 9h30 à 17h00 STRUCTURATION DE L'INFORMATION PATRIMONIALE. </ulink> <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. </phrase> </tocentry> 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. Fred.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]