Re: [Fwd: Evolution of the DocBook tools]

Re: [Fwd: Evolution of the DocBook tools]

[Eric Bischoff]

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

Jochem Huhmann wrote:

> There is another possible approach: A defined interface instead of a
> defined directory layout.

We could do both.

I have been reading your paper on the topic and it's a very
interesting approach. But now we have an opportunity to
define common directory names and catalog file names we
should take profit of it.

The scripts I've been rewriting also try to guess the
locations (a third approach), so they don't even need this
directory layout either. But I still think a common
directory layout would simplify things.

The problem is more general and is all what the Linux
Standard Base is about. I just want to solve it on the very
pecular DocBook side.

> So every distribution could use their own
> directories and filenames, but the interface stays the same. And some
> options to query the actual locations would allow other applications to
> find the location of the catalog and such. This would also work for
> FreeBSD, Solaris or whatever. Waiting for all Linux distributions and
> other Unix-Systems implement a common directory layout might take a long
> time, but an interface has just to be ported.

You're perfectly right. But as I said before, we can fight
on both fronts.

> PS: Jorge - if the new list barfs and you find a message of me causing

Jorge, did you change the list address ? I'm unable to write
to it, this is why I'm polluting docbook-tools-discuss
again.

Attached the new scripts (with the backends system) with the
corresponding man page drafts.

If a charity person can convert these drafts into good
docbook and send me the result, he would make me gain some
precious time. Thanks in advance.

Sorry to the non-interested people from this list about the
attachement.
 
-- 
 Éric Bischoff   -   mailto:ebisch@cybercable.tm.fr
 __________________________________________________
                                           \^o~_.
     .~.                           ______  /( __ )
     /V\         Toys story         \__  \/  (  V
   //   \\                            \__| (__=v
  /(     )\                        |\___/     )
    ^^-^^                           \_____(  )
     Tux                        Konqui     \__=v
 __________________________________________________
docbook-utils.tgz


[-- Attachment #2: docbook-utils.tgz --]
[-- Type: application/x-gzip, Size: 12342 bytes --]

Re: [Fwd: Evolution of the DocBook tools]

[Eric Bischoff]

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

Karl Eichwalder wrote:
> 
> Eric Bischoff <ebisch@cybercable.tm.fr> writes:
> 
> |   Here is your "official" invitation to an informal discussion on how
> |   to package the sgml tools (directory tree, contents of packages,
> |   utilities) in our various distributions. We will then formalize the
> |   results and send it as a proposal for the Linux Standard Base and
> |   the Docbook-Tools.
> 
> Thanks for your invitation.
> 
> I don't see the point why we shouldn't use the sgmltools list to discuss
> this issue...

Not to bother the other members. This discussion generates a
big traffic and people may get fed up with it. We'll go back
to the main list when we will have established a set of
proposals.

BTW, what's happening with our list at conectiva ? I'm
getting failure notices.

> OTOH, there isn't that much magic about SGML software as people often
> thing ;-)

Yes, but it's often puzzling them. I would like people being
able to use DocBook "out of the box" without hacking shell
scripts again and again.

> DTD, ENTITIES, and stylesheets sould go to /usr/share/$sgml (where $sgml
> should be "sgml", IMO).  (= $datadir)

This is one of the things we are discussing on the list, so
let's not start here.
(So far, most people are proposing /usr/lib/sgml, not
/usr/share/sgml, but the tools we are refining are versatile
enough to accept /usr/share/sgml or anything else)

> CATALOGs should go to $sysconfdir and links from
> /usr/share/$sgml/CATALOG.* might point to $sysconfdir/CATALOG.*

I think $sysconfdir is a SuSE-specific variable. I don't
understand you.
(So far, the catalogs are in the individual subdirectories,
and you can reference them through a centralized catalog
named /usr/lib/sgml/CATALOG)

> The name of the CATALOGs should be spelled in uppercase letter plus
> ".$package_name".

See above (we have for example
/usr/lib/sgml/docbook-dtd/docbook.cat, not
/usr/lib/sgml/CATALOG.docbook-dtd as you suggest).

> IMO, that's all what is needed.  If CATALOGs are there and properly
> detected, third party tools should work.

The db2* scripts I've been rewriting work either with :

/usr/lib/sgml/CATALOG (centralized catalog, if available)

or with :

/usr/lib/sgml/xxx/yyy.cat (if centralized catalog is not
available. They do a "find -name *.cat" to find them).

They accept an alternate SGML base directory like
/usr/share/sgml if you prefer this one.

> If you think this isn't enough, please, define the goals and provide a
> draft of the proposed implementation.

It's been done. I'll send it to you in a separate message
(but Jorge is reworking it, maybe it's better if Jorge can
send you the updated version).

Your message shows, if it was necessary, that each
distribution is doing a different thing, and that we have to
agree on common directory names and file names. Our
proposals will be used as a draft for the LSB, I have Ralf
Flaxa's agreement, and Mark Galassi may accept them as the
new Docbook-Tools distribution.

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

Re: [Fwd: Evolution of the DocBook tools]

[Eric Bischoff]

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

Jochem Huhmann wrote:
> 
> Guessing is guessing. What if someone has installed different
> stylesheets etc. installed? I've some from sgmltools (which came with
> jade and stylesheets and installs in /usr/local) and someone might have
> different versions installed by different packages in different but
> common locations. I don't like guessing.

I don't like it, but most users only need the basic
configuration. You can give the -d option if you have other
stylesheets. It's what we do at KDE.

> Yepp. Let's try to find the one and best locations for all files and
> directories, define this as default and standard and get it sacrified by
> the LSB - and make it configurable for the poor souls with systems not
> compliant to this standard.

Agree.

> > If a charity person can convert these drafts into good
> > docbook and send me the result, he would make me gain some
> > precious time. Thanks in advance.
> 
> I will look at it later. Thanks for the effort anyway,

Thanks for your help. They aren't long.

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

Re: [Fwd: Evolution of the DocBook tools]

[Jochem Huhmann]

* Eric Bischoff <ebisch@cybercable.tm.fr> wrote:
> Your message shows, if it was necessary, that each
> distribution is doing a different thing, and that we have to
> agree on common directory names and file names. 

I couldn't agree more. 

There is another possible approach: A defined interface instead of a
defined directory layout. So every distribution could use their own
directories and filenames, but the interface stays the same. And some
options to query the actual locations would allow other applications to
find the location of the catalog and such. This would also work for
FreeBSD, Solaris or whatever. Waiting for all Linux distributions and
other Unix-Systems implement a common directory layout might take a long
time, but an interface has just to be ported.


        Jochem

PS: Jorge - if the new list barfs and you find a message of me causing
this, please drop me a line. I've sent out the announcement with a lot
of Cc's, maybe some server in between has done funny things to it. Or I
was too tired to do it right. 

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

Re: [Fwd: Evolution of the DocBook tools]

[Jochem Huhmann]

* Eric Bischoff <ebisch@cybercable.tm.fr> wrote:
> Jochem Huhmann wrote:
> 
> > There is another possible approach: A defined interface instead of a
> > defined directory layout.
> 
> We could do both.

We even should. ;-)

> I have been reading your paper on the topic and it's a very
> interesting approach. But now we have an opportunity to
> define common directory names and catalog file names we
> should take profit of it.

We can define them (and we should), but we shouldn't rely on them. Look
at FreeBSD, at Solaris - we can make this as configurable as possible.

> The scripts I've been rewriting also try to guess the
> locations (a third approach), so they don't even need this
> directory layout either. But I still think a common
> directory layout would simplify things.

Guessing is guessing. What if someone has installed different
stylesheets etc. installed? I've some from sgmltools (which came with
jade and stylesheets and installs in /usr/local) and someone might have
different versions installed by different packages in different but
common locations. I don't like guessing.

> You're perfectly right. But as I said before, we can fight
> on both fronts.

Yepp. Let's try to find the one and best locations for all files and
directories, define this as default and standard and get it sacrified by
the LSB - and make it configurable for the poor souls with systems not
compliant to this standard. I would like to make no assumptions to rely
on wrt file locations. This is also a good test for being a valuable
tool for SGML-environments: if we make the script complete and
self-containing, you can query it anytime for the real, "official"
SGML-environment on the system it runs on. And use it to manipulate this
environment without having to know if it is compliant to the standard or
not. If "db --install-catalog /mnt/cdrom/fancy.cat" just adds these
entries to the catalog, you don't need to know where the catalog is at
all. And if "db --query catalog" returns the location of the catalog,
this is a great thing for other software that needs to know where the
catalog is (PSGML anyone?). It can just ask.

> Attached the new scripts (with the backends system) with the
> corresponding man page drafts.
> 
> If a charity person can convert these drafts into good
> docbook and send me the result, he would make me gain some
> precious time. Thanks in advance.

I will look at it later. Thanks for the effort anyway,


        Jochem

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