Re: (docbook-tools) What have we done so far ?

[Jorge Godoy <godoy@conectiva.com.br>]

On Mon, Mar 06, 2000 at 03:34:52PM -0600, Manoj Srivastava wrote:
> >>"Jorge" == Jorge Godoy <godoy@conectiva.com.br> writes:
> 
>  Jorge> Karl, you didn't understand me. I was asking the difference of
>  Jorge> having 20 direcotries in the /usr/share/sgml and in
>  Jorge> /usr/share/sgml/dtds.
> 
>         Currently, I have a single directrory. /usr/lib/sgml.dtd (soon to
>  become /usr/share/sgml/dtd/) with 61 DTD's in there. I have
>  html. xhtml. docbook (several versions) debiandoc, and linuxdoc stuff
>  in there. 
> 
>         Andthis machine does not have all my XML based DTD's that I am
>  rapidly having to use.

And wouldn't be easier to find these and their stylesheets if they
were in separate directories? 

>  Jorge> I don't think that it will be too crowded because there'll be no need
>  Jorge> to use lots of DTDs. Suppose that you use 20 different DTDs and 5 or 6
>  Jorge> stylesheets. It will be less than 30 directories there. And I don't
>  Jorge> know anybody who uses 20 DTDs with enough frequence!! That's too
>  Jorge> much. 
> 
>         And, of course, no one needs more than 640Kb Memory either
>         ;-)

No, but I don't see everyone out there using SGI clusters... 

>         Are we looking for a standard for docbook, or is this supposed
>  to be a general SGML/XML standard? 

The general standard is the better option. 

>         I think we should not be that short sighted when creating a
>  standard that is supposed to have a half life or more than a few
>  months. If the standard is not designed to accomodate several hundred
>  DTD's, it is not going to be adopted.

Again, what's easier to maintain: hundreds of files which may be DTDs,
stylesheets and catalogs or hundreds of directories which conatins
each DTD and it's stylesheets with a specific catalog? 

I'd rather be on a system with the last one. 

--
Godoy.	<godoy@conectiva.com.br> 

Setor de Publicações
Publishing Department                   Conectiva S.A.