[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: TR : RE : DOCBOOK: full recursive docbook
On Tue, Mar 18, 2003 at 01:54:15PM +0100, Frédéric Glorieux wrote: > > > Thanks for the links. > Was your server broken? Not that I know of. Did you have problems reaching it? > I had time to read your references, what I wrote yesterday seems to be > still useful. > > > You can set up modular docbook files using recursive > > 'section' elements. > > The problem is, if authors want to write sort of articles, with some > sectioning? (I know some who want it) > I'm not sure to be able to realize consequences, but > What about allow <article/> in <section/>? > Or allow <part/> in <part/>? Well, you would have to do some extensive customization of the DocBook DTD and XSL stylesheets to support that. > > > You can use XInclude to assemble them > > as needed. > > <?xml version="1.0"?> > > <!DOCTYPE section PUBLIC ...> > > <section id="startingpoint"> > > <title>Starting point</title> > > <para>Stuff for this starting file</para> > > <xi:include href="firstchild.xml" xmlns:xi="..." /> > > <xi:include href="secondchild.xml" xmlns:xi="..." /> > > ... > > </section> > > Do you mean that the <xi:include/> are generated by some app or > server, or are they hard coded in each section file ? I meant they could be generated. > In this case, I'm afraid of that. With a standard, users would > like to use a standard processor. But I don't know if it's easy to > control depth. For my case, generate a fast report for > france/region/department (without all cities). I haven't found things on > depth in the w3c recommendation for xinclude. For my fast own xsl > implementation, I need some proprietary attributes, which mean change > the > section file for each publishing. So a dynamic solution seems to be > needed. > > > You can use olinks to form links between them. > > Do you mean <olink/> for relative links like in website? I tried > it for a documentation project, it's possible for developers, not the > same for an architect, or an anthropologist. The olinking used in the currently released version of website is the old style entity olinks. The XSL stylesheets now support a newer olinking method that is easier to use. It still requires some setup by an administrator. It is described in the reference I sent you. > If my understanding is correct, that's why I'm oblige to propose > what is following (in case of recursive section, waiting for > section/article or a part/part/article solution). > > A strict reference file-tree structure (could be virtual on some > implementations like SQL, xml:db, or cocoon) > /section > section1.xml > section2.xml > section3.xml > _toc.xml (a docbook <toc/> file to keep order in this section) > /_config (with schemas, css, and other resources always useful > after a fast copy/paste for working outdoor for example, or for browser > navigation with no other applications) > /section1 (contains nestable sections for section1) > /config > _toc.xml > section1.1.xml > section1.2.xml > /section1.1 OK. > This quite rigid tree structure seems to solve author's links as > relative uri (../section1.1.xml), easy to understand (like in other html > site). I'm not clear on how you are forming your links. You can't specify a <xref linkend="../section1.1.xml"/> in your DocBook. This looks more like XLink, which is not implemented in DocBook. > Publish transformations need very low corrections (*.xml 2 > *.html, check if resource present, id for one file generation, pdf ?). > Don't have to maintain entity database for each added file. > Rebuild a valid docbook everywhere seems to be possible with the > same xsl > document((document('_toc.xml')/toc/tocpart/tocentry[@id=$the-section-i-n > eed]). > This is in tests on the <section/> granularity, but I would be > glad to have <article/> as leaves. Yes, but you won't get that without customizing the DTD yourself. > > With such deep nesting, you will likely run into > > issues of how to format titles for very deep > > hierarchies. The current XSL stylesheets only > > go about 6 levels deep. > > For this, happily, it's a detail. For html (which is first needed), I > suppose you let an <h6/> at the end, a CSS class could be added to keep > trace of level depth, and good luck to designers if they found styling > idea for each depth (and find reader for that). The goal is to let it > possible. Sure. 8^) -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 The SCO Group fax: (831) 429-1887 email: bobs@sco.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]