Re: Evolution of the DocBook tools

Re: Evolution of the DocBook tools

[Eric Bischoff]

Gregory Leblanc wrote:
> [snip]
> > Which programs don't recognize the CATALOG keyword? Jade and OpenJade
> > work with no problems. Programs that don't work aren't in accordance
> > with the specifications. Should we support them or "brake" them and
> > make the author improve their programs?
> 
> I'd break them, but I'm just a mean nasty guy...

;-)
The best is to offer the choice.

> > The problem with "iso-entities" is that some stylesheets refer to them
> > on it's catalog. Making a patch in a packaged distribution (RPM, deb,
> > etc.) is easy, but I don't know if it's good in a plain .tar.gz
> > distribution (of course, a note saying that files were modified and
> > the like would be enough).
> 
> When everything gets hashed out, just make a .tar.gz.  I'm quite sure that
> we can get a .spec file written for RPMs, either by myself or somebody who's
> better at it.  debs should be easy to make from there.

Already done (the .tar.gz and the .spec)

Rest of the discussion on the new list please.

-- 
Eric Bischoff  -  Documentation and Localization
Caldera (Deutschland) GmbH - Linux for Business!
Tel: +49 9131 7192 300 -  Fax: +49 9131 7192 399
http://www.caldera.de/

RE: Evolution of the DocBook tools

[Gregory Leblanc]

Please, mail the list when that list is online, I'm enjoying this
discussion.

> -----Original Message-----
> From: Jorge Godoy [ mailto:godoy@conectiva.com.br ]
> Sent: Thursday, February 24, 2000 4:45 AM
> To: Eric Bischoff
> Cc: docbook-tools-discuss@sourceware.cygnus.com
> Subject: Re: Evolution of the DocBook tools
> 
[snip]
> Which programs don't recognize the CATALOG keyword? Jade and OpenJade
> work with no problems. Programs that don't work aren't in accordance
> with the specifications. Should we support them or "brake" them and
> make the author improve their programs? 

I'd break them, but I'm just a mean nasty guy...

> The problem with "iso-entities" is that some stylesheets refer to them
> on it's catalog. Making a patch in a packaged distribution (RPM, deb,
> etc.) is easy, but I don't know if it's good in a plain .tar.gz
> distribution (of course, a note saying that files were modified and
> the like would be enough). 

When everything gets hashed out, just make a .tar.gz.  I'm quite sure that
we can get a .spec file written for RPMs, either by myself or somebody who's
better at it.  debs should be easy to make from there.
	Greg
Sun Hardware Reference Maintainer
http://sun-ref.sunhelp.org/

Evolution of the DocBook tools

[Eric Bischoff]

Jorge Godoy wrote:
>
> You might have several catalogs merged in your personal catalog
> file. How? You can add a `CATALOG "file.cat"' in it and it will
> "automagically" include the other catalog.
>

I tried it again :

[eric@quark kedit]$ cat /usr/lib/sgml/CATALOG
CATALOG iso-entities-8879.1986/iso-entities.cat
CATALOG jade/dsssl.cat
CATALOG docbook-dtd/docbook.cat
CATALOG docbook-stylesheets/nwalsh-modular.cat

and it works !

Now I remember : the CATALOG keyword doesn't work with Arbortext Epic,
that's why I had to find another solution.
Norm, do you confirm ?

So we should offer the choice : either merge catalogs, either not, but
yes, install-catalog should take profit of the CATALOG keyword.

--
Eric Bischoff  -  Documentation and Localization
Caldera (Deutschland) GmbH - Linux for Business!
Tel: +49 9131 7192 300 -  Fax: +49 9131 7192 399
http://www.caldera.de/

Re: Evolution of the DocBook tools

[Eric Bischoff]

Jorge Godoy wrote:
 
> If we don't accept merging catalogs, we ar going to allow users
> specifying catalog at the command line. He (the user) will have to

I didn't say "not accept to merge catalogs", but I said "accept not to
merge catalogs" ;-)

> say:
> 
> - Where's jade/openjade stylesheets
> - Where's DocBook stylesheets
> - Where is/are his customized stylesheets.

No. The user has the choice to have a merged CATALOG file, or not to
have one. If he hasn't, the db2html script tries to use the "standard"
places, which are defined by the directory layout we are discussing. I
tell you, my scripts are quite intelligent ;-)

(BTW, The user can also use --catalog option if he has an extra catalog,
and --nostd option if he doesn't want these standard places. Everything
is free to the user, but the default is not to type anything)

> The command typed would be huge and subject to typing errors. I don't
> think it's a good approach...

See above.
-- 
Eric Bischoff  -  Documentation and Localization
Caldera (Deutschland) GmbH - Linux for Business!
Tel: +49 9131 7192 300 -  Fax: +49 9131 7192 399
http://www.caldera.de/

Re: Evolution of the DocBook tools

[Jorge Godoy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5057 bytes --]

On Thu, Feb 24, 2000 at 12:55:46PM +0100, Eric Bischoff wrote:
> Jorge Godoy wrote:
> > 
> > 
> > You might have several catalogs merged in your personal catalog
> > file. How? You can add a `CATALOG "file.cat"' in it and it will
> > "automagically" include the other catalog.
> 
> Of course you can do a lot of things manually. But what I was saying is
> that a standard installation needed the "install-catalog" script (or
> some equivalent mechanism if you want to use the CATALOG keyword) to be
> installed *early* with respect to the other packages.

I understood what you said now. Sorry.

> But yes, it's true, "install-catalog" could be improved to use the
> CATALOG keyword instead of really merging the catalog themselves. But
> wasn't there a problem with the CATALOG keyword that wasn't supported by
> jade or something else ?

I use it here for a few months now and I have no problem with it. 

> > Look at "conectiva.cat" in the file I've sent you in the other
> > message. It solves lots of problems and you don't need to merge an
> > entire new catalog each time a new release is done. And, besides, you
> > use the stylesheets catalog with all it's relative paths. It works
> > wonderfully.
> 
> You're mentioning another problem that I hadn't been speaking about :
> merging catalogs implied that the other packages couldn't be in their
> own directory, because the relative paths became relative to the merged
> CATALOG file. There are two
> ways to work around this (if not more) :
> - accept not to merge catalogs in the db2* scripts (my solution)
> - use the CATALOG keyword (your solution)
> 
> but sure, the best would be to offer the choice between both solutions,
> therefore to enhance install-catalog script, with the restriction that I
> can remember the CATALOG keyword not to be recognized by some programs.
> My db2* scripts accept both a merged catalog or separate catalogs, the
> first having the priority, of course.

IMHO, if we want not interfere with the stylesheets used and want tro
allow a generic use of these tools, there are few alternatives: 

- Using the CATALOG directive
- Using the DELEGATE directive
- Merging CATALOG files (would require that we _change_ the specified
  paths!)  

I think the first two are the best. If the stylesheet/DTD is well
written and has a well formed catalog file, the first directive is the
best (it's easier to implement and we don't need to know anything
about what's in this specific catalog). 

The second would require that we know at least some part of the
declarations being used. It's possible, but requires more work.

The third is the most space expensive and needs more work than the
first two. I won't work this way, but if you think it's easier, go
ahead. 

Which programs don't recognize the CATALOG keyword? Jade and OpenJade
work with no problems. Programs that don't work aren't in accordance
with the specifications. Should we support them or "brake" them and
make the author improve their programs? 

> > > That's what I did for Caldera, and I'll keep it unless Debian has
> > > different names with a clean directory layout too. It would be stupid to
> > > have only two-letter differences... ;-)
> > 
> > I'm doing some work at Conectiva Linux on that too.
> > I'm using /usr/lib/sgml and then creating subdirectories with each
> > stylesheet. It's still a mess, but I'm cleaning it up.
> 
> Same idea for what I did. What are your directory names ? I chose :
> 
> docbook-dtd  docbook-stylesheets  iso-entities-8879.1986  jade  kde 
> 
> Let's all take the same names, if you accept. I also suggest "gnome" for
> Gnome project customizations  and "ldp" for Linux Documentation Project
> customizations.
> 
> And I think it is becoming urgent that Mark should give us his blessing,
> so those evolutions become "official" ;-)


Ok... I'm using a slightly different notation:

/usr/lib/sgml
 - docbook-3.1
 - docbook-3.0
 - docbook-4.0beta
 - docbook-2.4
 - docbook-2.4.1
 - docbook-version (generalization! I don't have this directory)
 - jade
 - iso-entities-8879.1986 (this is from sgmltools 1.09, not DocBook related)
 - gnome (as you suggested)
 - ldp (they don't have a stylesheet for DocBook yet...)
 - kde (they have it?)

Numbering DocBook DTDs and stylesheets is needed. We have some
documents in DocBook 2.4 (and they don't work with 3.1 files) and new
documents are being written in newer versions of DocBook. 

The problem with "iso-entities" is that some stylesheets refer to them
on it's catalog. Making a patch in a packaged distribution (RPM, deb,
etc.) is easy, but I don't know if it's good in a plain .tar.gz
distribution (of course, a note saying that files were modified and
the like would be enough). 

BTW, there's another problem regarding iso-entities: sgmltools use
them with upper case (ISOamsa) and Norm's stylesheets use it with
lower case and an extension (isoamsa.gml). It's another
standardization issue. 

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

Setor de Publicações
Publishment Division                   Conectiva S.A.

Re: Evolution of the DocBook tools

[Eric Bischoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

Peter Ring wrote:
> 
> Keep talking!
> 
> I've been waiting for this subject to get some real focus. It seemed
> that most SGML tool developers were happy hacking their means of
> distribution (including introducing silly variants of SGML Open catalog
> files), which is fine as long as you can pretend to own the poor users'
> namespace. Well, you don't.
> (snipped)
> Comments? Thoughts?

There is really a need for a good namespace.

Join us on the new list, we will make a presentation of
everyone's good ideas like your ones, and then reach a
consensus. When the recommandations will be agreed by
anyone, we will present them and try to make them accepted
as a standard.


-- 
 Éric Bischoff   -   mailto:ebisch@cybercable.tm.fr
 __________________________________________________
                                           \^o~_.
     .~.                           ______  /( __ )
     /V\         Toys story         \__  \/  (  V
   //   \\                            \__| (__=v
  /(     )\                        |\___/     )
    ^^-^^                           \_____(  )
     Tux                        Konqui     \__=v
 __________________________________________________

Re: Evolution of the DocBook tools

[Eric Bischoff]

Jorge Godoy wrote:

> I think the same. Isn't it subject for a new list? I can create one to
> discuss it. It might be called "sgml-packages" and be hosted here at
> Conectiva. Or, if nobody on this list gets bored, we might continue
> talking here...

I think we are starting to bore everyone here ;-). Let's go for a new
list to discuss the details (please subscribe me in). Any distribution
packager, or any interested person is welcome, and of course Mark
Galassi's presence would be great. I'll have David Baudens which is
packaging the same stuff at Mandrake join us as well. David Mason, are
you interested to represent RedHat for that ? It would be great to have
a Debian packager as well, but I don't know any.

We'll present the results afterwards to this list, and submit them for
approval to Mark Galassi. I think it's the more efficient and
transparent way to proceed.

-- 
Eric Bischoff  -  Documentation and Localization
Caldera (Deutschland) GmbH - Linux for Business!
Tel: +49 9131 7192 300 -  Fax: +49 9131 7192 399
http://www.caldera.de/

Evolution of the DocBook tools

[Eric Bischoff]

Jorge Godoy wrote:
> 
> 
> You might have several catalogs merged in your personal catalog
> file. How? You can add a `CATALOG "file.cat"' in it and it will
> "automagically" include the other catalog.

Of course you can do a lot of things manually. But what I was saying is
that a standard installation needed the "install-catalog" script (or
some equivalent mechanism if you want to use the CATALOG keyword) to be
installed *early* with respect to the other packages.

But yes, it's true, "install-catalog" could be improved to use the
CATALOG keyword instead of really merging the catalog themselves. But
wasn't there a problem with the CATALOG keyword that wasn't supported by
jade or something else ?

> Look at "conectiva.cat" in the file I've sent you in the other
> message. It solves lots of problems and you don't need to merge an
> entire new catalog each time a new release is done. And, besides, you
> use the stylesheets catalog with all it's relative paths. It works
> wonderfully.

You're mentioning another problem that I hadn't been speaking about :
merging catalogs implied that the other packages couldn't be in their
own directory, because the relative paths became relative to the merged
CATALOG file. There are two
ways to work around this (if not more) :
- accept not to merge catalogs in the db2* scripts (my solution)
- use the CATALOG keyword (your solution)

but sure, the best would be to offer the choice between both solutions,
therefore to enhance install-catalog script, with the restriction that I
can remember the CATALOG keyword not to be recognized by some programs.
My db2* scripts accept both a merged catalog or separate catalogs, the
first having the priority, of course.

> > That's what I did for Caldera, and I'll keep it unless Debian has
> > different names with a clean directory layout too. It would be stupid to
> > have only two-letter differences... ;-)
> 
> I'm doing some work at Conectiva Linux on that too.
> I'm using /usr/lib/sgml and then creating subdirectories with each
> stylesheet. It's still a mess, but I'm cleaning it up.

Same idea for what I did. What are your directory names ? I chose :

docbook-dtd  docbook-stylesheets  iso-entities-8879.1986  jade  kde 

Let's all take the same names, if you accept. I also suggest "gnome" for
Gnome project customizations  and "ldp" for Linux Documentation Project
customizations.

And I think it is becoming urgent that Mark should give us his blessing,
so those evolutions become "official" ;-)

-- 
Eric Bischoff  -  Documentation and Localization
Caldera (Deutschland) GmbH - Linux for Business!
Tel: +49 9131 7192 300 -  Fax: +49 9131 7192 399
http://www.caldera.de/

RE: Evolution of the DocBook tools

[Peter Ring]

Keep talking!

I've been waiting for this subject to get some real focus. It seemed
that most SGML tool developers were happy hacking their means of
distribution (including introducing silly variants of SGML Open catalog
files), which is fine as long as you can pretend to own the poor users'
namespace. Well, you don't.

We try putting together a directory structure for the kind of 'things'
that SGML tools share, based on James Clark's design for the entity
manager in sgmls (refer to
http://www.uic.edu/~cmsmcq/tech/sgmls.entities.html ). The idea is to
find a pattern that is easy to understand and implement, so that anyone
(e.g. a program) would come up with the same directory structure, given
the FPI for an entity. The structure must allow for different releases
of 'the same' entities, and we'd like to use the resulting directory
structure as a name space that also manages related processing tools,
scripts and stylesheets. Some of the processing tools use the directory
structure as part of a name space, e.g. Python.

Comments? Thoughts? 

Kind regards,
Peter Ring


-----Original Message-----
From: Jorge Godoy [ mailto:godoy@conectiva.com.br ]
Sent: Thursday, February 24, 2000 3:11 PM
To: Eric Bischoff
Cc: docbook-tools-discuss@sourceware.cygnus.com
Subject: Re: Evolution of the DocBook tools

<snip>

> All of this discussion, according to me, shows that it was necessary to
> embetter the docbook-tools distribution, and to normalize the choices.

I think the same. Isn't it subject for a new list? I can create one to
discuss it. It might be called "sgml-packages" and be hosted here at
Conectiva. Or, if nobody on this list gets bored, we might continue
talking here... 

<snip>

Re: Evolution of the DocBook tools

[Eric Bischoff]

Jorge Godoy wrote:
> 
> IMHO, if we want not interfere with the stylesheets used and want tro
> allow a generic use of these tools, there are few alternatives:
> 
> - Using the CATALOG directive
> - Using the DELEGATE directive
> - Merging CATALOG files (would require that we _change_ the specified
>   paths!)

- plus a fourth one, letting db2* scripts determine where are the
catalogs (my solution)

Among the first three ones, only the first one is really good, IMHO.

The third one was chosen by the current DocBook-tools and implied a
dirty directory layout if you don't want to re-work the paths. And this
had bad consequences if you wanted to use alternate stylesheets.

> Which programs don't recognize the CATALOG keyword? Jade and OpenJade
> work with no problems. Programs that don't work aren't in accordance
> with the specifications. Should we support them or "brake" them and
> make the author improve their programs?

Now I remember Epic does not recognize this keyword.

> > Same idea for what I did. What are your directory names ? I chose :
> >
> > docbook-dtd  docbook-stylesheets  iso-entities-8879.1986  jade  kde
> >
> > Let's all take the same names, if you accept. I also suggest "gnome" for
> > Gnome project customizations  and "ldp" for Linux Documentation Project
> > customizations.
> >
> > And I think it is becoming urgent that Mark should give us his blessing,
> > so those evolutions become "official" ;-)
> 
> Ok... I'm using a slightly different notation:
> 
> /usr/lib/sgml
>  - docbook-3.1
>  - docbook-3.0
>  - docbook-4.0beta
>  - docbook-2.4
>  - docbook-2.4.1
>  - docbook-version (generalization! I don't have this directory)
>  - jade
>  - iso-entities-8879.1986 (this is from sgmltools 1.09, not DocBook related)
>  - gnome (as you suggested)
>  - ldp (they don't have a stylesheet for DocBook yet...)
>  - kde (they have it?)

Yes, kde customization is available in package "kdesdk", subdirectory
"ksgmltools/customization"

Why don't you put the stylesheets at the same level as the dtd ? it
allows to change the stylesheets version, without changing the dtd, in a
simpler way (there are more stylesheet versions than dtd ones).

Docbook DTD and stylesheets numbering is a really good idea, indeed. It
looks like you went even further in the reflexion than I did ;-). What
about making a symbolic link from the generic name to the numbered name
? Like : docbook-dtd -> docbook-dtd-4.0beta.

Iso-entities are not only needed by sgmltools 1.09, but by jade as well.
Maybe you have them duplicate, just check.

So I suggest :

/usr/lib/sgml
  docbook-dtd-2.4
  docbook-dtd-2.4.1
  docbook-dtd-3.1
  docbook-dtd-3.0
  docbook-dtd-4.0beta
  docbook-dtd -> docbook-dtd-3.1
  docbook-sylesheets-1.49
  docbook-sylesheets-1.50
  docbook-sylesheets-1.51
  docbook-sylesheets-1.52
  docbook-stylesheets -> docbook-stylesheets-1.52
  jade
  iso-entities-8879.1986
  gnome
  ldp
  kde

> The problem with "iso-entities" is that some stylesheets refer to them
> on it's catalog. Making a patch in a packaged distribution (RPM, deb,
> etc.) is easy, but I don't know if it's good in a plain .tar.gz
> distribution (of course, a note saying that files were modified and
> the like would be enough).

I have been adding a catalog for them in iso-entities-8879.1986, the one
that was in sgml-tools-1.09 ;-) I searched a lot, even on ISO web
servere, but I was unable to find something that looked "official". So I
just did like the others and took what was available...

> BTW, there's another problem regarding iso-entities: sgmltools use
> them with upper case (ISOamsa) and Norm's stylesheets use it with
> lower case and an extension (isoamsa.gml). It's another
> standardization issue.

I was about to say it. I took :

ISOamsa  ISOamsc  ISOamso  ISObox   ISOcyr2  ISOgrk1  ISOgrk3  ISOlat1 
ISOnum  ISOtech
ISOamsb  ISOamsn  ISOamsr  ISOcyr1  ISOdia   ISOgrk2  ISOgrk4  ISOlat2 
ISOpub  iso-entities.cat

I had to remove the DTD catalog entries to have them shared between
sgml-tools and the modular stylesheets. Maybe it's not the right
solution, but it works (and anyway, this catalog had to be patched,
because it uses the DTDDECL keyword which is not supported by Jade).
Tell me if you have found a better solution.

All of this discussion, according to me, shows that it was necessary to
embetter the docbook-tools distribution, and to normalize the choices.
-- 
Eric Bischoff  -  Documentation and Localization
Caldera (Deutschland) GmbH - Linux for Business!
Tel: +49 9131 7192 300 -  Fax: +49 9131 7192 399
http://www.caldera.de/

Re: Evolution of the DocBook tools

[Jorge Godoy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5394 bytes --]

On Thu, Feb 24, 2000 at 02:36:06PM +0100, Eric Bischoff wrote:
> Jorge Godoy wrote:
> > 
> > IMHO, if we want not interfere with the stylesheets used and want tro
> > allow a generic use of these tools, there are few alternatives:
> > 
> > - Using the CATALOG directive
> > - Using the DELEGATE directive
> > - Merging CATALOG files (would require that we _change_ the specified
> >   paths!)
> 
> - plus a fourth one, letting db2* scripts determine where are the
> catalogs (my solution)

How to find them? They are named:

- catalog
- CATALOG
- anything.cat
- put your catalog name here... 

> Among the first three ones, only the first one is really good, IMHO.
> 
> The third one was chosen by the current DocBook-tools and implied a
> dirty directory layout if you don't want to re-work the paths. And this
> had bad consequences if you wanted to use alternate stylesheets.

That was what I said... :-) 

> > Which programs don't recognize the CATALOG keyword? Jade and OpenJade
> > work with no problems. Programs that don't work aren't in accordance
> > with the specifications. Should we support them or "brake" them and
> > make the author improve their programs?
> 
> Now I remember Epic does not recognize this keyword.

Hmmm... I didn't know it. 
The question is the same: force them to be compliant with the specs or
make a workaround? Workareounds are dangerous... We'll have to make it
for every program that's not compliant with it... 

> Why don't you put the stylesheets at the same level as the dtd ? it
> allows to change the stylesheets version, without changing the dtd, in a
> simpler way (there are more stylesheet versions than dtd ones).

Wait... What stylesheets are you talking about? I have another
directory that I forgot listing:

/usr/lib/sgml
 - modular-stylesheets

which is Norm's modular stylesheets. 

If this is the stylesheets you are talking about, it's already done. 

> Docbook DTD and stylesheets numbering is a really good idea, indeed. It
> looks like you went even further in the reflexion than I did ;-). What
> about making a symbolic link from the generic name to the numbered name
> ? Like : docbook-dtd -> docbook-dtd-4.0beta.

I don't think it's a good idea and it isn't even needed. The
declaration at the beginning of the document specifies what to use and
the catalogs do the rest of the magic. 

> Iso-entities are not only needed by sgmltools 1.09, but by jade as well.
> Maybe you have them duplicate, just check.

I've checked. Actually, they aren't duplicated. My jade requires a
"sgml-common" package which provides these files. I made a workaround
to the "case" problem using symlinks.

> So I suggest :
> 
> /usr/lib/sgml
>   docbook-dtd-2.4
>   docbook-dtd-2.4.1
>   docbook-dtd-3.1
>   docbook-dtd-3.0
>   docbook-dtd-4.0beta
>   docbook-dtd -> docbook-dtd-3.1
>   docbook-sylesheets-1.49
>   docbook-sylesheets-1.50
>   docbook-sylesheets-1.51
>   docbook-sylesheets-1.52
>   docbook-stylesheets -> docbook-stylesheets-1.52
>   jade
>   iso-entities-8879.1986
>   gnome
>   ldp
>   kde

I don't see why symlinking docbook-dtd to a numbered directory. As I
said, let the catalogs do the magic. 

> > The problem with "iso-entities" is that some stylesheets refer to them
> > on it's catalog. Making a patch in a packaged distribution (RPM, deb,
> > etc.) is easy, but I don't know if it's good in a plain .tar.gz
> > distribution (of course, a note saying that files were modified and
> > the like would be enough).
> 
> I have been adding a catalog for them in iso-entities-8879.1986, the one
> that was in sgml-tools-1.09 ;-) I searched a lot, even on ISO web
> servere, but I was unable to find something that looked "official". So I
> just did like the others and took what was available...

I used symlinks. ;-) Not the best option, thought. I'll have to make a
package with them and then adapt all the other. 

> > BTW, there's another problem regarding iso-entities: sgmltools use
> > them with upper case (ISOamsa) and Norm's stylesheets use it with
> > lower case and an extension (isoamsa.gml). It's another
> > standardization issue.
> 
> I was about to say it. I took :
> 
> ISOamsa  ISOamsc  ISOamso  ISObox   ISOcyr2  ISOgrk1  ISOgrk3  ISOlat1 
> ISOnum  ISOtech
> ISOamsb  ISOamsn  ISOamsr  ISOcyr1  ISOdia   ISOgrk2  ISOgrk4  ISOlat2 
> ISOpub  iso-entities.cat

I changed as little as possible the DTDs. The symlinks in a specific
package might solve the problem... 

> I had to remove the DTD catalog entries to have them shared between
> sgml-tools and the modular stylesheets. Maybe it's not the right
> solution, but it works (and anyway, this catalog had to be patched,
> because it uses the DTDDECL keyword which is not supported by Jade).
> Tell me if you have found a better solution.

A new package. Which DTD are you talking about? I remember patching
one, but now I don't remember which one... :-)

> All of this discussion, according to me, shows that it was necessary to
> embetter the docbook-tools distribution, and to normalize the choices.

I think the same. Isn't it subject for a new list? I can create one to
discuss it. It might be called "sgml-packages" and be hosted here at
Conectiva. Or, if nobody on this list gets bored, we might continue
talking here... 


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

Setor de Publicações
Publishment Division                   Conectiva S.A.

Re: Evolution of the DocBook tools

[Jorge Godoy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

On Thu, Feb 24, 2000 at 12:55:46PM +0100, Eric Bischoff wrote:

Sorry! I forgot one thing:

> > Look at "conectiva.cat" in the file I've sent you in the other
> > message. It solves lots of problems and you don't need to merge an
> > entire new catalog each time a new release is done. And, besides, you
> > use the stylesheets catalog with all it's relative paths. It works
> > wonderfully.
> 
> You're mentioning another problem that I hadn't been speaking about :
> merging catalogs implied that the other packages couldn't be in their
> own directory, because the relative paths became relative to the merged
> CATALOG file. There are two
> ways to work around this (if not more) :
> - accept not to merge catalogs in the db2* scripts (my solution)
> - use the CATALOG keyword (your solution)

If we don't accept merging catalogs, we ar going to allow users
specifying catalog at the command line. He (the user) will have to
say:

- Where's jade/openjade stylesheets
- Where's DocBook stylesheets
- Where is/are his customized stylesheets.

The command typed would be huge and subject to typing errors. I don't
think it's a good approach... 


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

Setor de Publicações
Publishment Division                   Conectiva S.A.