From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jorge Godoy To: Eric Bischoff Cc: docbook-tools-discuss@sourceware.cygnus.com Subject: Re: Evolution of the DocBook tools Date: Wed, 27 Dec 2000 06:36:00 -0000 Message-id: <20000224104506.L24290@conectiva.com.br> References: <951281049.19725.ezmlm@sourceware.cygnus.com> <20000223085415.B611@ciberia.es> <38B3ABD6.71623993@cybercable.tm.fr> <38B40C05.FD198BAE@cybercable.tm.fr> <38B51C42.41B72A89@cybercable.tm.fr> X-SW-Source: 2000/msg00089.html 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. Setor de Publicações Publishment Division Conectiva S.A.