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: Re : db2??????? vs. SGMLTools2 vs. what else?


* Eric Bischoff <ebisch@cybercable.tm.fr> wrote:
> Jochem Huhmann wrote:
> > 
> > * Eric Bischoff <ebisch@cybercable.tm.fr> wrote:
> > > (seeking a greater compatibility
> > > with Debian could also be a concern, BTW).
> > 
> > OK. What I meant is: There is some software like jade and the
> > stylesheets. There are a lot of wrappers around these - Marks tools, the
> > scripts from SuSE, the KDE-stuff and SGMLTools (for the most part a
> > wrapper written in python).
> 
> Hmmm, looks like a big mixture. Which KDE-stuff is in ???
> I think we should not copy their packaging, but at least adopt the same
> directory names if possible.
> What is the result of a 'ls /usr/lib/sgml' on a debian ?

Sorry, no, I don't talk only about Debian. The tools (and file locations
and such) needed to process SGML with jade and DSSSL are packaged in a
different way in every single Linux-Distribution and sometimes there are
also additional packages, which do this in one more different way. 

One should see that "docbook-tools" actually are "tools for processing
SGML with jade", not "tools for processing DocBook". The tool-chain for
processing a DocBook file may also include eg. Emacs with PSGML (for
editing) and also PSGML needs to know where to find the catalog. If
someone wants to use or to write other tools for processing DocBook he
also needs some basics to rely on. So you *can't* wrap up everything and
put it in one package again and again. If there where some common
standard for file locations and catalog handling, the user could plug in
whatever he needs or wants and every application could rely on finding
things.

I would like to see a situation where a software developer just can use
a Makefile to build HTML and Postscript versions of his software
documentation on a Linux system, *without* to care about the wrappers
and tools and file locations found on a random distribution. We will
never get there if Caldera and Redhat and SuSE and Debian come with
their own wrappers and file-locations.

I see that you are trying to get this mess cleared up and that's great,
but IMHO this has to be discussed with authors of other wrappers and
maintainers of packages. I'm using Redhat systems since 4.0, Caldera
since that "Caldera Network Desktop 1.0", Debian since 2.0 and SuSE
since "S.u.S.E. 11/94"; if getting software compiled would have been
such a mess as getting a SGML file rendered to a readable or printable
format I never would have bothered with Linux.

> > Actually I believe this is an issue for the LSB or FHS-Projects. Caldera
> > is also member of LSB and is responsible for the reference
> > implementation, or am I wrong?
> 
> You're perfectly true.
> 
> > Maybe you should ask Ralf Flaxa
> > <rf@lst.de> who is assigned as technical lead for this task. Or ask on
> 
> He's currently in the US and quite busy, but sure, I'll speak with him
> about that when I'll meet him again.
> 
> > one of the LSB-lists.
>
> Yup.

Looks like you (or someone else) should write up a proposal, post it to
lsb-discuss@lists.linuxbase.org and cc it to all the maintainers and
packagers and related lists (like sgml-tools@via.ecp.fr)... I'm quite
sure that a lot of people being busy with regard to DocBook on Linux (or
FreeBSD, which is quite comfortable with DocBook, the FreeBSD-Handbook
is DocBook) are not reading this list.



        Jochem

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

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