[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE : TR : RE : DOCBOOK: full recursive docbook
> > 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. Customizing docbook is possible, but losing compatibility with standard tools is a great lost... this is the very last option. So my question is more precisely, do you plan for one day to support such constructions? The goal I purchase is perhaps of general interest, a "leave-file" is an article, able to go in a one "file-tree" standard docbook, or to be the page of a website (static or dynamic). Very large software documentation project could find use of such things (sorry for the reference, I think of the infinite? Microsoft.msdn tree) Before that, tricky things on sections are possible. Resolve the author ones, and the ones appended by engine. @id, order wishes, funny overriding effects possible, but not sure that authors will like it. [xinclude] > I meant they could be generated. Perhaps then xinclude should be reserved to authors [with no depth control], and engine use its own way. [a file-tree structure, made for collaborative work in a "not-always-connected-world", where all folders are able to live alone or in parents] > OK. Is it an opinion? Is <toc/> usage not abusive? > 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. I imagine to use <ulink/> with relative url, #id support, and perhaps xpointer() if some want it. That means my own matcher of <ulink/> in case of no protocol://. The links will be broken after standard transformation, sad but not a too big problem. Working on the URI string is perhaps enough for our simple needs (because there's also very complex needs, "semantic links" it's called, probably outside the docbook namespace). It could also be resolved in a publishing framework (cocoon like), or parsed for some SQL. Thanks for help. ----------------------------------------------------------- Frédéric Glorieux frederic.glorieux@ajlsm.com AJLSM (33) 05 57 14 25 22 Conseil et dévelopement 17 rue Vital-Carles en Informatique documentaire 33 000 Bordeaux France
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]