[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK-APPS: html-xslt comments, questions, requests
On Sun, Jul 07, 2002 at 11:49:43PM -0400, Vincent-Olivier Arsenault wrote: > Hey all! > > First I'd like to congratulate all the contributors to the XSLT package, > because it is a very, very handy tool! > > I'm using the HTML templates of the 1.52 version of the XSLT distro. > > Here are my user notes.. > > > ######################## > # 1. <div> generation # > ######################## > Looking at the resulting code, I find that there are tons of <div>s > everywhere (some of them have no attributes). > > I am wondering if it could be possible to have an elegant way of turning > it off without rewriting about 40 big templates (maybe with a > "make.block.div" parameter containing the docbook element(s) to be > transformed into <div>s)... > > Anyways, it's because <div>s in html also carry presentation > instructions that are irreversible using CSS: for example, they won't > flow around floated elements no matter what you do (unless I missed > something)... Well, I thought the divs were there to *enable* CSS control by supplying class names to be used as selectors. At least, that's how I use them. > > > ######################################################### > # 2. chunk names and URLs for permanent web addressing # > ######################################################### > I think having the chunks named in a hierarchical way (using > directories) would be a great feature for people who would like to > render a complete web site out of a single docbook document, because : > > 1. URL should represent the structure of the information so that it is > easy for the user to know where he is. > > 2. URL should be descriptive of their content. > > Also, link paths and chunking path should be generated differently. For > example, in the case of an href, > > (a) "/myBook/myPart/myChapter/" > > is better than > > (b) "/myBook/myPart/myChapter/index.html" > > Because while they will both get you the resource you want, (a) allows > the webmaster to change to another server side technology (that would > change the file name to "/myBook/myPart/mychapter/index.php", in the > case of PHP) without having to redirect or to issue 404. Another reason > for that, more obvious, is that (a) is smaller and that the file part in > (b) is not descriptive of its content. XSLT doesn't have a built-in feature to create directories, so building the output tree would have to be done with extensions. Another approach is to put your path sequence in the id attribute of your chunk elements and set the 'use.id.as.filename' parameter to 1. You can't use "/", but you can use "-" or "_". For example: <chapter id="myBook_myPart_myChapter"> would produce a file named "myBook_myPart_myChapter.html". Also, have you looked at the 'website' extension of DocBook to build websites? It's available for download from http://sourceforge.net/projects/docbook/ > > ############### > # 3. preface # > ############### > I would like the preface to be part of the book's chunk. Would that be > semantically correctly, is there another way to get text on a book chunk? I'm not sure what the "book chunk" is. The top level chunk for a book is the title page, which may include a legalnotice, and does include the TOC. Are you referring to the title page as the book chunk? > > ################################ > # 4. ToC in a separate chunk # > ################################ > MMM, would it be great to have the possibility to put the table of > content in a separate chunk and to be able to specify its path? Or maybe > it can be done already? I haven't seen this, but I think it could be a nice feature. So the title page would have a link to "Table of Contents", right? This would be similar to the 'generate.legalnotice.link' parameter. > And if there is code to contribute to do that, I'm willing to help. I > just thought it would be nice to have some directions from the authors > and also indications on whether those features are OK to include in the > distro. Docbook is a community project, so contributions are welcome. > > ps : Has anybody tried Adobe Framemaker 7? It supposedly supports XML > docbook. Our copywriters would need a "m$-world-like" app in order to > have a full docbook publishing pipeline. Any related experiences, advices? Check the docbook-apps archive for June, as there was some discussion there. -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: bobs@caldera.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC