Re: DOCBOOK-APPS: html-xslt comments, questions, requests

[Bob Stayton <bobs@caldera.com>]

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