[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: TR : RE : DOCBOOK: full recursive docbook
Thanks for the links. Was your server broken? 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/>? > 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 ? 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. 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 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). 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. > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]