This is the mail archive of the docbook-tools-discuss@sourceware.cygnus.com mailing list for the docbook-tools project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Evolution of the DocBook tools


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]