Re: was something else - now SGML and XML

Re: was something else - now SGML and XML

[David Mason]

< 200002231540.KAA08528@devserv.devel.redhat.com >
< 7453-Wed23Feb2000110215-0500-ndw@nwalsh.com >
X-URL: < http://www.redhat.com >
From: "David C. Mason" <dcm@redhat.com>
Date: 23 Feb 2000 11:43:04 -0500
Message-ID: <y9xk8jv3m5j.fsf@devserv.devel.redhat.com>
Lines: 12
X-Mailer: Gnus v5.7/Emacs 20.5

Norman Walsh <ndw@nwalsh.com> writes:

> If you're referring to IE5 support for XSL, it's so badly broken
> that it's just about useless. (Worse than useless, in fact.)

Is that true - I, obviously, don't use IE but I see a lot of traffic on
the DocBook lists from people who do and despite the fact that they
are usually trying to work around some problem - there sure seems to
be a lot of people using it. Is that true or am I trapped in a good
marketing scheme?

Dave

Re: was something else - now SGML and XML

[Norman Walsh]

/ David Mason <dcm@redhat.com> was heard to say:
| > If you're referring to IE5 support for XSL, it's so badly broken
| > that it's just about useless. (Worse than useless, in fact.)
| 
| Is that true - I, obviously, don't use IE but I see a lot of traffic on
| the DocBook lists from people who do and despite the fact that they

Which lists?

| are usually trying to work around some problem - there sure seems to
| be a lot of people using it. Is that true or am I trapped in a good
| marketing scheme?

It doesn't support <xsl:number>, or variables, or named
templates, or a half a dozen other things. I've toyed with XSL
stylesheets for sdocbook, but you can't even number footnotes or
sections fer cryin' out loud.

I'm sure there are lots of people trying to use it, and they've
got my sympathy. If you're doing server-side stuff with tabular
XML data extracted from some database and your injecting it into
HTML coded in some other tool, it probably does some job fairly
well. But that's not a job I have to do, thank goodness!

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Curiosity never killed anything
http://nwalsh.com/                 | except maybe a few hours.

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[David Mason]

< 200002231510.KAA30278@devserv.devel.redhat.com >
< 38B3FF81.40E6F034@cybercable.tm.fr >
X-URL: < http://www.redhat.com >
From: "David C. Mason" <dcm@redhat.com>
Date: 23 Feb 2000 10:52:21 -0500
Message-ID: <y9xwvnvzzka.fsf@devserv.devel.redhat.com>
Lines: 25
X-Mailer: Gnus v5.7/Emacs 20.5

Eric Bischoff <ebisch@cybercable.tm.fr> writes:


> Stop, stop, stop, I don't want to start no flame war.

Not my intention - why does everyone think I am angry at them this
week? Jeez.

When you say the scripts are unmaintained I think you are wrong. Mark
is the maintainer of DocBook Tools - DocBook Tools include those
scripts. Instead of announcing you are going to maintain those
scripts, why not ask Marks if you can send some patches to him or get
cvs access to make some changes. You can see by the number of people
already asking you for tarballs that this can cause a split in the
project. I'd like to see more concentration on this project AND some
new projects that do things differently. I would not like to see a
project splinter and confuse. That is just my opinion.

Again, I am not flaming you, I am not upset at you, in fact,
throughout our conversations over the year - I like you.. I too want
to see changes made to the scripts - hell I hack them up on my own
machine and ignore the ones that ship anyway.


Dave

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[Eric Bischoff]

David Mason wrote:
> When you say the scripts are unmaintained I think you are wrong. Mark
> is the maintainer of DocBook Tools - DocBook Tools include those
> scripts.

Well, it's what I have been reading in all docbook tool packages. And
when I have been proposing a patch to db2ps to make it work with
alternate stylesheets, I never had any answer, but maybe Mark was too
busy to integrate this patch.

> Instead of announcing you are going to maintain those
> scripts, why not ask Marks if you can send some patches to him or get
> cvs access to make some changes. You can see by the number of people

Done. I've been asking this directly to Mark a few weeks ago. Again, no
answer. Mark may be on holliday, though. I did not want to make my
projects public, because I wanted to hear Mark's opinion before, but
people were wondering what existed as docbook tools, and some were
starting to say that they did not use them.

I don't think that CVS concurrent access for me would be a good idea,
because the changes are too radical to be done without approval from
Mark.

> already asking you for tarballs that this can cause a split in the
> project. I'd like to see more concentration on this project AND some
> new projects that do things differently. I would not like to see a
> project splinter and confuse. That is just my opinion.

You're perfectly right.

> Again, I am not flaming you, I am not upset at you, in fact,
> throughout our conversations over the year - I like you.. I too want

I love you too. Kiss me ;-)

> to see changes made to the scripts - hell I hack them up on my own
> machine and ignore the ones that ship anyway.

I just tried to do something simple, clean and robust that would need
less hacking.

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

[Horacio MG]

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

> I've made some wrappers and a Makefile for dealing with standard
> DocBook tools. I'll be packaging them soon (RPM and, of course,
> SRPM). I can send them to you. They are commented out in Portuguese,
> but when I package them they'll have comments in English and a
> "README" :-)

Hi, could you send me a tarball of the sources, please?  (no rpms)

> I don't use Cygnus tools (don't ask me why :-)). 

I'd like to ask why though.


TIA

-- 
Horacio					Anno MMDCCLIII aUC
homega@ciberia.es			Valencia - ESPAÑA
--------------------------------------------------------------------
Key fingerprint = F4EE AE5E 2F01 0DB3 62F2  A9F4 AD31 7093 4233 7AE6

Re: db2??????? vs. SGMLTools2 vs. what else?

[Jorge Godoy]

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

On Wed, Feb 23, 2000 at 08:54:15AM +0100, Horacio MG wrote:
> > I've made some wrappers and a Makefile for dealing with standard
> > DocBook tools. I'll be packaging them soon (RPM and, of course,
> > SRPM). I can send them to you. They are commented out in Portuguese,
> > but when I package them they'll have comments in English and a
> > "README" :-)
> 
> Hi, could you send me a tarball of the sources, please?  (no rpms)

Sure... I'll do that. I'm starting today (I'm stuck with some
projects, and I'll do this and go back to them). 

> > I don't use Cygnus tools (don't ask me why :-)). 
> 
> I'd like to ask why though.

Mainly because of don't knowing they existed and, then, because of
their standard appearance. I like to have control of what's
happening. In many cases, a script is better than an executable
because of that: you know what's happening and you can change it.

Regards,
--
Godoy.	<godoy@conectiva.com.br>               GPG Fingerprint
                                         851B B620 626D 2AD0 E783
"Ser poeta não é minha ambição,          E932 1330 BE6D A4A3 0625 
 é minha maneira de estar sozinho"
              - Fernando Pessoa.       Publicações @ Conectiva S.A. 

Except where explicitly stated I speak on my own behalf.
Exceto onde explicitado as declarações aqui feitas são apenas minhas.

Re : db2??????? vs. SGMLTools2 vs. what else?

[Eric Bischoff]

Announcement :

I have been repackaging completly the DocBook tools and
rewritten all db* utilities.

What I have been seeking is :
- to have the db2* scripts change their status from "unmaintained"
  to "maintained"
- to have better directory organization in /usr/lib/sgml
- to have things work better with alternate stylesheets
- to make as little assumptions as possible : no
  "common" stylesheet for html and printout if not wished,
  no need of merging the individual catalogs in a single CATALOG
  if not wished, etc
- gnuish syntax
- compatibility (if no alternate stylesheets used) with
  former docbook-tools

My distribution will be used by Caldera OpenLinux and KDE project. I'm
proposing to
make it the standard docbook-tools as well, if you agree. Just let me
know.

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

[Jorge Godoy]

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

On Wed, Feb 23, 2000 at 10:43:50AM +0100, Eric Bischoff wrote:
> Announcement :
> 
> I have been repackaging completly the DocBook tools and
> rewritten all db* utilities.
> 
> What I have been seeking is :
> - to have the db2* scripts change their status from "unmaintained"
>   to "maintained"

It would be nice...

> - to have better directory organization in /usr/lib/sgml

It depends on your distribution. How's you /usr/lib/sgml? I've done a
few customizations here... :-) 

> - to have things work better with alternate stylesheets

I do it with a wrapper, a Makefile and standar tools: jade/openjade &
norm's modular stylesheets. 

> - to make as little assumptions as possible : no
>   "common" stylesheet for html and printout if not wished,
>   no need of merging the individual catalogs in a single CATALOG
>   if not wished, etc

It's not difficult. That's one of the reasons I don't use Cygnus
tools. 

> - gnuish syntax

Hmmm... It would require some programming, but... it's possible too. 

> - compatibility (if no alternate stylesheets used) with
>   former docbook-tools

What do you mean by "compatibility"? If your document is written in
DocBook, it should be compatible with any tools used to process
DocBook files.

> My distribution will be used by Caldera OpenLinux and KDE project. I'm
> proposing to
> make it the standard docbook-tools as well, if you agree. Just let me
> know.

If you need some help, just drop me a message. 


--
Godoy.	<godoy@conectiva.com.br>               GPG Fingerprint
                                         851B B620 626D 2AD0 E783
"Ser poeta não é minha ambição,          E932 1330 BE6D A4A3 0625 
 é minha maneira de estar sozinho"
              - Fernando Pessoa.       Publicações @ Conectiva S.A. 

Except where explicitly stated I speak on my own behalf.
Exceto onde explicitado as declarações aqui feitas são apenas minhas.

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[Eric Bischoff]

Jorge Godoy wrote:
> > - to have the db2* scripts change their status from "unmaintained"
> >   to "maintained"
> 
> It would be nice...

(I would be the maintainer of those db2* scripts, of course)

> > - to have better directory organization in /usr/lib/sgml
> 
> It depends on your distribution. How's you /usr/lib/sgml? I've done a
> few customizations here... :-)

My distribution is the Caldera ;-). Here is /usr/lib/sgml organization

[eric@quark eric]$ ls /usr/lib/sgml
docbook-dtd
docbook-stylesheets
iso-entities-8879.1986
jade
kde

"iso-entities" directory name is the only one which does not match the
package name, to ensure compatibility with sgml-tools 1.0 linuxdoc
tools.

The DocBook tools hosted by Cygnus sourceware FTP server suggest a
different directory organisation, at least if you are using the RPM
version.

> > - to have things work better with alternate stylesheets
> 
> I do it with a wrapper, a Makefile and standar tools: jade/openjade &
> norm's modular stylesheets.

Of course every one can build his own solution. At KDE we used a series
of symbolic links as patches to the Cygnus tools. What I'm suggesting is
a good common technical solution for everyone.

> > - to make as little assumptions as possible : no
> >   "common" stylesheet for html and printout if not wished,
> >   no need of merging the individual catalogs in a single CATALOG
> >   if not wished, etc
> 
> It's not difficult. That's one of the reasons I don't use Cygnus
> tools.

;-)

I didn't say I made something difficult. I said I wanted to share my
experience and to integrate it into the Cygnus docbook tools, with Mark
Galassi's approval and technical advice, of course.

> > - gnuish syntax
> 
> Hmmm... It would require some programming, but... it's possible too.

It's not much again. You will be able to do things like db2html
--version, db2html --help, db2html --catalog somewhere.cat, etc

> > - compatibility (if no alternate stylesheets used) with
> >   former docbook-tools
> 
> What do you mean by "compatibility"? If your document is written in
> DocBook, it should be compatible with any tools used to process
> DocBook files.

I was referring to those famous db2* scripts, the ability to use the
CATALOG merged by "install-catalog" script, etc.

> > My distribution will be used by Caldera OpenLinux and KDE project. I'm
> > proposing to
> > make it the standard docbook-tools as well, if you agree. Just let me
> > know.
> 
> If you need some help, just drop me a message.

Thanks, the more crazy cows we are, the funniest the meat will be ;-)

What I need now is some approval by docbook-tools maintainer, Mark
Galassi, and somewhere to build a docbook-utils homepage (docbook-utils
being the set of db2* scripts, plus the install-catalog script, which I
suggest to be separate from the modular stylesheets package now).
 

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

[Jochem Huhmann]

* Eric Bischoff <ebisch@cybercable.tm.fr> wrote:
> My distribution will be used by Caldera OpenLinux and KDE project. I'm
> proposing to make it the standard docbook-tools as well, if you
> agree. Just let me know.

Could you be so kind and put the package up on ftp? Maybe also as tar.gz
for all of us without a RPM-based Linux (or Linux at all). You should
also contact the Debian Project which might also be interested in this
(you will probably at least get some help in packing this up as
Debian-Package, which would be nice to have for a "standard
docbook-tool"). Also SuSE might be interested, since they have such
scripts of their own.

I would also decide on a new name for the tools, all this db2something
is quite confusing. What about "doctool"?


        Jochem

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

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[Eric Bischoff]

Jochem Huhmann wrote:
> 
> * Eric Bischoff <ebisch@cybercable.tm.fr> wrote:
> > My distribution will be used by Caldera OpenLinux and KDE project. I'm
> > proposing to make it the standard docbook-tools as well, if you
> > agree. Just let me know.
> 
> Could you be so kind and put the package up on ftp? Maybe also as tar.gz
> for all of us without a RPM-based Linux (or Linux at all). You should

Caldera is a RPM-based distribution, so my packaging will probably be
only profitable for those with RPM-based distributions, like the current
DocBook tools that only offer a mirror of the source packages for those
without RPM. Furthermore, I have been told the Debian project already
did a very clean packaging of its own (seeking a greater compatibility
with them could also be a concern, BTW).

Of course the new db2* scripts do not depend on the packaging and I can
send them to you.

I don't want to put anything on KDE's ftp before I know my help proposal
is accepted or refused here : as David said, there's no need to multiply
the distributions.

> also contact the Debian Project which might also be interested in this
> (you will probably at least get some help in packing this up as
> Debian-Package, which would be nice to have for a "standard
> docbook-tool"). Also SuSE might be interested, since they have such
> scripts of their own.

Sure, we should at least seek a common directory layout.

I think the reference version is here at the DocBook tools, so I won't
start anything on my own before Mark gives his advice on the topic.

> I would also decide on a new name for the tools, all this db2something
> is quite confusing. What about "doctool"?

Currently, the docbook-stylesheets package from the docbook-tools
includes three things :
1 - Norman Walsh's modular stylesheets
2 - the db2* and install-catalog scripts
3 - some "glue" files like "cygnus-common.dsl"

I think that (1) has to be packaged separately for modularity reasons, I
suggest to rename (2) the "docbook-utils" (only a component of the
docbook-tools), and to get rid of (3) because this kind of files imply a
lot of assumptions on the way you are working.

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

[Jochem Huhmann]

* Eric Bischoff <ebisch@cybercable.tm.fr> wrote:
> Caldera is a RPM-based distribution, so my packaging will probably be
> only profitable for those with RPM-based distributions, like the current
> DocBook tools that only offer a mirror of the source packages for those
> without RPM. Furthermore, I have been told the Debian project already
> did a very clean packaging of its own (seeking a greater compatibility
> with them 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). The software should be packaged like any
other software, I don't see the point in putting it together with
scripts and such. This creates conflicts with other packages. Try to
install the SGMLTools (which come with the stylesheets and jade)
together with other packages, that also install the stylesheets. This is
a mess and every single Linux-Distribution comes up with it's own
mess. This is not part of a solution but a part of the problem.

> Currently, the docbook-stylesheets package from the docbook-tools
> includes three things :
> 1 - Norman Walsh's modular stylesheets
> 2 - the db2* and install-catalog scripts
> 3 - some "glue" files like "cygnus-common.dsl"
> 
> I think that (1) has to be packaged separately for modularity reasons, I
> suggest to rename (2) the "docbook-utils" (only a component of the
> docbook-tools), and to get rid of (3) because this kind of files imply a
> lot of assumptions on the way you are working.

There should be some "standard" for directory layout, location of the
catalog etc. Wrappers should build upon this common standard. So you
could use whichever you want.  

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? Maybe you should ask Ralf Flaxa
<rf@lst.de> who is assigned as technical lead for this task. Or ask on
one of the LSB-lists.


        Jochem

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

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

[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/

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[Eric Bischoff]

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 ?

> The software should be packaged like any
> other software, I don't see the point in putting it together with
> scripts and such.

That's my opinion as well, it is the reason why I have been putting
Mark's scripts (reworked by myself) in a new separate package named
"docbook-utils". Mark could not do this before because the
install-catalog script needed to be called very early, and this was
because the scripts could only work with a merged CATALOG... Now it is
an option to merge the catalogs, and therefore there's no more need to
package the scripts along with some other package, and the dependancies
are clean. (BTW, a strange consequence of the former situation was that
the uninstalling failed at the end, because install-catalog was removed
while it was still necessary for the uninstallation. Snake eating its
tail...)

> This creates conflicts with other packages. Try to
> install the SGMLTools (which come with the stylesheets and jade)
> together with other packages, that also install the stylesheets. This is
> a mess and every single Linux-Distribution comes up with it's own
> mess. This is not part of a solution but a part of the problem.

SGML-Tools are not any longer maintained, so I don't want to rely on
that. I'm sure Cees De Groot would understand perfectly.

> There should be some "standard" for directory layout, location of the
> catalog etc. Wrappers should build upon this common standard. So you
> could use whichever you want.

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... ;-)

> 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.

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

[Jochem Huhmann]

* 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!

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[Jorge Godoy]

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

On Thu, Feb 24, 2000 at 11:00:58AM +0100, Eric Bischoff wrote:
> Jochem Huhmann wrote:

> > The software should be packaged like any
> > other software, I don't see the point in putting it together with
> > scripts and such.
> 
> That's my opinion as well, it is the reason why I have been putting
> Mark's scripts (reworked by myself) in a new separate package named
> "docbook-utils". Mark could not do this before because the
> install-catalog script needed to be called very early, and this was
> because the scripts could only work with a merged CATALOG... Now it is
> an option to merge the catalogs, and therefore there's no more need to
> package the scripts along with some other package, and the dependancies
> are clean. (BTW, a strange consequence of the former situation was that
> the uninstalling failed at the end, because install-catalog was removed
> while it was still necessary for the uninstallation. Snake eating its
> tail...)

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. 

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. 

> > There should be some "standard" for directory layout, location of the
> > catalog etc. Wrappers should build upon this common standard. So you
> > could use whichever you want.
> 
> 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. 

--
Godoy.	<godoy@conectiva.com.br>               GPG Fingerprint
                                         851B B620 626D 2AD0 E783
"Ser poeta não é minha ambição,          E932 1330 BE6D A4A3 0625 
 é minha maneira de estar sozinho"
              - Fernando Pessoa.       Publicações @ Conectiva S.A. 

Except where explicitly stated I speak on my own behalf.
Exceto onde explicitado as declarações aqui feitas são apenas minhas.

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/

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

[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

[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.

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[Eric Bischoff]

Jochem Huhmann wrote:
> 
> 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.

This is exactly what I have been starting. The problem with the current
DocBook tools is that everything is mixed up in /usr/lib/sgml, so I
wouldn't say it is a good base for standardization. Of course starting a
new directory layout is not a way of standardizing things, but the
previous messages in this list show that I haven't been the only one to
feel that need.

> 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.

100% agree.

> 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.

Yeap. But here is maybe the greater place to do this standardization
work, because it is the only maintained and active project. We can make
the things more official in front of LSB if needed afterwards.

> 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.

Can you do that as soon as we have the technical details mailing list
set up and running ? I'm not familiar with these lists you're
mentioning.
-- 
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: Re : db2??????? vs. SGMLTools2 vs. what else?

[Jochem Huhmann]

* Eric Bischoff <ebisch@cybercable.tm.fr> wrote:
> Can you do that as soon as we have the technical details mailing list
> set up and running ? I'm not familiar with these lists you're
> mentioning.

I will chase down all related lists and a few individuals to mail a
short announcement to this weekend. Or post it to comp.text.sgml and cc
it to the lists and recipients. I will also do a cc to this list, OK?

It would also be nice to have a web archive of the list, which is IMHO
quite valuable in such cases.


        Jochem

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

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[Eric Bischoff]

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

Jochem Huhmann wrote:
> 
> * Eric Bischoff <ebisch@cybercable.tm.fr> wrote:
> > Can you do that as soon as we have the technical details mailing list
> > set up and running ? I'm not familiar with these lists you're
> > mentioning.
> 
> I will chase down all related lists and a few individuals to mail a
> short announcement to this weekend. Or post it to comp.text.sgml and cc
> it to the lists and recipients. I will also do a cc to this list, OK?

Yes, I think that unfortunately it will take all the
week-end to have all the major actors join in.

I will take profit of this week-end to prepare a descriptive
paper of the purpose of this list, and a list the practical
issues we could discuss. I'd like the list to be temporary,
efficient, technical, and democratic ;-).


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

New list (was Re: Re : db2??????? vs. SGMLTools2 vs. what else?)

[Jorge Godoy]

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

I've setup a list (temporary?) for disscussing it:

To subscribe send a message to
docbook-tool-subscribe@bazar.conectiva.com.br and reply to the
confirmation message. Send messages to list at
docbook-tools@bazar.conectiva.com.br.
You can unsubscribe by sending a message to
docbook-tools-unsubscribe@bazar.conectiva.com.br and replying the
confirmation message or (in a slower way) writing to me. 

Please, all the interested on this issue subscribe to this list. 
Procmail rules can be made with the "Mailing-List" header :-) 

Sorry for the extra traffic here. 


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

Setor de Publicações
Publishing Department                   Conectiva S.A.

Re: New list (was Re: Re : db2??????? vs. SGMLTools2 vs. what else?)

[Jochem Huhmann]

* Jorge Godoy <godoy@conectiva.com.br> wrote:
> I've setup a list (temporary?) for disscussing it:
> 
> To subscribe send a message to
> docbook-tool-subscribe@bazar.conectiva.com.br and reply to the
          ^^^^

> confirmation message. Send messages to list at
> docbook-tools@bazar.conectiva.com.br.
          ^^^^^

Is this "docbook-tool" or "docbook-tools"?

> You can unsubscribe by sending a message to
> docbook-tools-unsubscribe@bazar.conectiva.com.br and replying the
          ^^^^^

"docbook-tools" probably... 


        Jochem

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

Re: New list (was Re: Re : db2??????? vs. SGMLTools2 vs. what else?)

[Jorge Godoy]

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

On Thu, Feb 24, 2000 at 07:16:56PM -0200, Jorge Godoy wrote:
> I've setup a list (temporary?) for disscussing it:
> 
> To subscribe send a message to
> docbook-tool-subscribe@bazar.conectiva.com.br and reply to the
> confirmation message. Send messages to list at
> docbook-tools@bazar.conectiva.com.br.
> You can unsubscribe by sending a message to
> docbook-tools-unsubscribe@bazar.conectiva.com.br and replying the
> confirmation message or (in a slower way) writing to me. 
> 
> Please, all the interested on this issue subscribe to this list. 
> Procmail rules can be made with the "Mailing-List" header :-) 
> 
> Sorry for the extra traffic here. 

A small correction:

docbook-tools-subscribe@bazar.conectiva.com.br


There was one missing "s". :-( Typo error...


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

Setor de Publicações
Publishing Department                   Conectiva S.A.

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[David Mason]

< 200002231510.KAA30278@devserv.devel.redhat.com >
< 6289-Wed23Feb2000102546-0500-ndw@nwalsh.com >
X-URL: < http://www.redhat.com >
From: "David C. Mason" <dcm@redhat.com>
Date: 23 Feb 2000 10:40:59 -0500
Message-ID: <y9xzossylis.fsf@devserv.devel.redhat.com>
Lines: 38
X-Mailer: Gnus v5.7/Emacs 20.5

Norman Walsh <ndw@nwalsh.com> writes:

> / David Mason <dcm@redhat.com> was heard  to say:
> | Don't misunderstand me either - I say the more tools we have *the
> | better*! In fact, I'd like to see more tools for XML (that aren't
> | java) for the simple reason that once DocBook hits 5.0 it will
> only be
> | XML.
> 
> While true, I think that's a somewhat misleading statement.
> DocBook 5.0 will be an XML DTD, but XML *is* SGML, so
> it will be an SGML DTD as well. :-)

While true, ;) XML is becoming more and more its own beast in more
ways than one. The simple fact that our current tools don't handle it
well makes it *in reality* something different for the poor souls who
had to move from starting things off with <!DOCTYPE Book PUBLIC
"-//OASIS//DTD DocBook V4.0//EN"[]> to <?xml version="1.0"
standalone="no"?>.

And on the *nix platforms we don't have it as easy as those of you on
MS related products as we have no good tools to process XML
(IMHO). Sure jade handles it to some extent, even against dsssl, but
it doesn't handle XSL... There are a few java based tools available
but the java engines for *nix stink thanks to Sun... Someone has
threatened to put XSL support in Mozilla but backed down at the last
second..

So tell me in my *real world* setting how similar XML is to SGML
despite its continual claim that it is merely a 'subset' of SGML. If
it was just that why does XSL have to come along? why do new tools
have to be written? etc.

But despite all that, the thrust of my argument was that I don't want
yet another project called DocBook Tools! (which is not a DTD)


Dave

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[Norman Walsh]

/ David Mason <dcm@redhat.com> was heard to say:
| > While true, I think that's a somewhat misleading statement.
| > DocBook 5.0 will be an XML DTD, but XML *is* SGML, so
| > it will be an SGML DTD as well. :-)
| 
| While true, ;) XML is becoming more and more its own beast in more
| ways than one. The simple fact that our current tools don't handle it
| well makes it *in reality* something different for the poor souls who
| had to move from starting things off with <!DOCTYPE Book PUBLIC
| "-//OASIS//DTD DocBook V4.0//EN"[]> to <?xml version="1.0"
| standalone="no"?>.

There are some authoring changes (system identifiers, empty tag
syntax, etc.), but the only thing the tools have to do
differently is pass an appropriate SGML declaration to, e.g.,
Jade.

| And on the *nix platforms we don't have it as easy as those of you on
| MS related products as we have no good tools to process XML
| (IMHO). Sure jade handles it to some extent, even against dsssl, but
| it doesn't handle XSL... There are a few java based tools available
| but the java engines for *nix stink thanks to Sun... Someone has
| threatened to put XSL support in Mozilla but backed down at the last
| second..

Huh? Jade and the Java based XSL tools ought to be damn near the
same.  If you're referring to IE5 support for XSL, it's so badly
broken that it's just about useless. (Worse than useless, in fact.)

I'm doing everything I do with XML using Jade and XT. Well,
except for editing which I sometimes use, um, Arbortext products
for, no surprise, and they aren't available for Linux (more's
the pity) but they sure are available for Unix.

| So tell me in my *real world* setting how similar XML is to SGML
| despite its continual claim that it is merely a 'subset' of SGML. If
| it was just that why does XSL have to come along? why do new tools
| have to be written? etc.

I'll save some of my wilder theories for a chat over a beer some
night, but the simpler answer is that the new tools are coming
along because XML is easier to process than SGML. XML is mostly
marketing.

New tools *don't have to be written*. All your existing SGML
tools work just fine.

| But despite all that, the thrust of my argument was that I don't want
| yet another project called DocBook Tools! (which is not a DTD)

I'm staying out of that one. :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Fast. Cheap. Well. Pick two.
http://nwalsh.com/                 | 

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[David Mason]

< 20000223085415.B611@ciberia.es > < 38B3ABD6.71623993@cybercable.tm.fr >
X-URL: < http://www.redhat.com >
From: "David C. Mason" <dcm@redhat.com>
Date: 23 Feb 2000 10:10:57 -0500
Message-ID: <y9x900c0xa6.fsf@devserv.devel.redhat.com>
Lines: 25
X-Mailer: Gnus v5.7/Emacs 20.5

Eric Bischoff <ebisch@cybercable.tm.fr> writes:

> Announcement :
> 
> I have been repackaging completly the DocBook tools and
> rewritten all db* utilities.



If you name this one "DocBook Tools it will be the third maintained
DocBook Tools. Whatever you might think, Mark is still maintaining
DBTools unless he states otherwise. Another fellow has written a
version for Suse and is using the name, and now you are planning to
make changes and use the name. 

This is just going to cause *great* confusion for the *nix users who
want good tools. 'Just grab DocBook Tools' "WHICH ONE!!!"

Please consider renaming it unless Mark gives you maintainer or
contributor status!

Don't misunderstand me either - I say the more tools we have *the
better*! In fact, I'd like to see more tools for XML (that aren't
java) for the simple reason that once DocBook hits 5.0 it will only be
XML.

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[Norman Walsh]

/ David Mason <dcm@redhat.com> was heard to say:
| Don't misunderstand me either - I say the more tools we have *the
| better*! In fact, I'd like to see more tools for XML (that aren't
| java) for the simple reason that once DocBook hits 5.0 it will only be
| XML.

While true, I think that's a somewhat misleading statement.
DocBook 5.0 will be an XML DTD, but XML *is* SGML, so
it will be an SGML DTD as well. :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Reality is what refuses to go away
http://nwalsh.com/                 | when I stop believing in
                                   | it.--Philip K. Dick

Re: Re : db2??????? vs. SGMLTools2 vs. what else?

[Eric Bischoff]

David Mason wrote:
> 
> Eric Bischoff <ebisch@cybercable.tm.fr> writes:
> 
> > Announcement :
> >
> > I have been repackaging completly the DocBook tools and
> > rewritten all db* utilities.
> 
> If you name this one "DocBook Tools it will be the third maintained
> DocBook Tools. Whatever you might think, Mark is still maintaining
> DBTools unless he states otherwise. Another fellow has written a

Stop, stop, stop, I don't want to start no flame war.

Mark is maintaining the DocBook tools, this is established and I don't
want to change that.
I was just proposing some enhancements.

I am only proposing myself as the maintainer for the db2* scripts which
have officially "unmaintained" status.

> version for Suse and is using the name, and now you are planning to
> make changes and use the name.

No, no. I am politely suggesting some changes.

> This is just going to cause *great* confusion for the *nix users who
> want good tools. 'Just grab DocBook Tools' "WHICH ONE!!!"

Quiet, slow down, David. I am precisely proposing some enhancements
*here* to avoid another split.

> Please consider renaming it unless Mark gives you maintainer or
> contributor status!

That's it : I just want to contribute.

> Don't misunderstand me either - I say the more tools we have *the
> better*! In fact, I'd like to see more tools for XML (that aren't
> java) for the simple reason that once DocBook hits 5.0 it will only be
> XML.

No, there's no use to have *more tools* if they do exactly the same
thing.

Let me sum up things : when I started looking for some docbook packages
for the KDE project, inspired by your great work for the Gnome project,
David, I had the following opportunities :

- grab the many components (jade, the stylesheets, the jadetex macros,
the iso entities, etc) in several places. No thanks, collecting
mushrooms is only funny when walking outdoors.

- use the sgml-tools 2.0. No way, this project has been suspended

- use the docbook-tools. Hey, fine ! Mark has already been doing the job
!

then we have been using these tools for some time, and run into
problems, that we have fixed with patches, and now I'd like to make the
others profit of my experience. That's all.

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

[Mark Galassi]

    >> If you name this one "DocBook Tools it will be the third
    >> maintained DocBook Tools. Whatever you might think, Mark is
    >> still maintaining DBTools unless he states otherwise. Another
    >> fellow has written a

    Eric> Stop, stop, stop, I don't want to start no flame war.

    Eric> Mark is maintaining the DocBook tools, this is established
    Eric> and I don't want to change that.  I was just proposing some
    Eric> enhancements.

Wow, more deference which I have not been deserving in the last 90
days...

    Eric> I am only proposing myself as the maintainer for the db2*
    Eric> scripts which have officially "unmaintained" status.

That was a disclaimer that *Cygnus* was not maintaining those tools;
sorry about the confusion.

I'm getting closer to catching up on the list, and it looks like we
are hitting critical mass for the next generation effort, even before
I stepped in.

Re: was something else - now SGML and XML

[David Mason]

< 200002231540.KAA08528@devserv.devel.redhat.com >
< 7453-Wed23Feb2000110215-0500-ndw@nwalsh.com >
X-URL: < http://www.redhat.com >
From: "David C. Mason" <dcm@redhat.com>
Date: 23 Feb 2000 11:26:42 -0500
Message-ID: <y9xu2izzxz1.fsf@devserv.devel.redhat.com>
Lines: 52
X-Mailer: Gnus v5.7/Emacs 20.5

Norman Walsh <ndw@nwalsh.com> writes:

> There are some authoring changes (system identifiers, empty tag
> syntax, etc.), but the only thing the tools have to do
> differently is pass an appropriate SGML declaration to, e.g.,
> Jade.

Like I said - this is true. I know that. But something like empty tag
syntax is something that will affect the writer when then finally
change the heading on their doc and wonder why the hell it gets
errors. The problem is not that I can't handle the changes coming or
work around the available tools to work with XML - I can - but the new
contributor to the doc project I work on who happens to have come from
the Word Processor world and just can't quite grasp this stuff needs a
little more help than what jade and XT provide. And to try to merge
someone who is willing to help through changes like you mention above
sometimes means losing that volunteer. I spend most of my time
figuring out how to keep them around and not scare them off. DocBook
itself sometimes scares them off without even trying it out. 

> I'm doing everything I do with XML using Jade and XT. Well,
> except for editing which I sometimes use, um, Arbortext products
> for, no surprise, and they aren't available for Linux (more's
> the pity) but they sure are available for Unix.

When is that port coming anyway? ;)

> I'll save some of my wilder theories for a chat over a beer some
> night, but the simpler answer is that the new tools are coming
> along because XML is easier to process than SGML. XML is mostly
> marketing.
> 
> New tools *don't have to be written*. All your existing SGML
> tools work just fine.


So the beer I'm up for - but are you telling me that Jade will parse
XML against XSL? It doesn't do that and, it won't do that anytime soon
as far as I can tell. XT is fine if you want to write code around it
to do some parsing testing but its not finished, and like I said - its
a new tool being written.

Its very similar situation to the introduction of XSL - which, on the
surface, appears to be a rewrite of dsssl with < >'s so that people
will understand it better (or something). Its introduction is not only
stealing away from the work done on dsssl tools, but as you say
yourself "They would also work just fine with the straight DocBook
DTD, but I'm not aware of any XSL processors that parse SGML
documents." - well DocBook XML *is* SGML isnt it? :)


Dave

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

[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/

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

[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]

[-- 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
 __________________________________________________