Docbook on Mandrake 7.2/8.0

Docbook on Mandrake 7.2/8.0

[Gary Stainburn]

Hi all,

I've just come back to docbook after not using it for a while - the 
last time I used it was about 3 years ago using the then current rpms 
installed onto RedHat 5.2.

I'm now on Mandrake 7.2, and within a day or two will upgrade to 8.0.

My problem is that when I try to run one of my old documents through 
db2pdf I get shedloads of errors and a useless pdf file.

As far as I can tell, I've got the appropriate rpm's installed, but I 
don't know where to go from here.  I didn't understand the workings 
back in '99, I just used it.  I think it's got something to do with the 
first line.

Here's my first line as it is in the document, and the first few lines 
of errors.  The second set is what happened when I changed it to look 
the same as the one in Docbook:TDG.

<!doctype book PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [

[gary@gary revcom]$ db2pdf pmrintro.sgml
Using stylesheet: 
"/usr/share/sgml/docbook/dsssl-stylesheets-cygnus/stylesheets/cygnus-both.dsl"
jade:pmrintro.sgml:1:59:W: cannot generate system identifier for public 
text "-//Davenport//DTD DocBook V3.0//EN"
jade:pmrintro.sgml:8:0:E: reference to entity "BOOK" for which no 
system identifier could be generated
jade:pmrintro.sgml:1:0: entity was defined here
jade:pmrintro.sgml:8:0:E: DTD did not contain element declaration for 
document type name
jade:pmrintro.sgml:9:5:E: element "BOOK" undefined
jade:pmrintro.sgml:10:11:E: element "BOOKINFO" undefined
jade:pmrintro.sgml:11:9:E: element "DATE" undefined
jade:pmrintro.sgml:12:10:E: element "TITLE" undefined

[Modified]

<!doctype book PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [

[gary@gary revcom]$ db2pdf pmrintro.sgml
Using stylesheet: 
"/usr/share/sgml/docbook/dsssl-stylesheets-cygnus/stylesheets/cygnus-both.dsl"
jade:E: cannot open 
"/usr/lib/sgml/stylesheets/nwalsh-modular/print/docbook.dsl" (No such 
file or directory)
jade:E: specification document does not have the DSSSL architecture as 
a base architecture
This is pdfTeX, Version 3.14159-13d (Web2C 7.3.1)
(pmrintro.tex[/usr/share/texmf/pdftex/config/pdftex.cfg]
JadeTeX 2000/06/20: 2.20
(/usr/share/texmf/tex/latex/psnfss/t1ptm.fd)
Elements will be labelled
Jade begin document sequence at 2
(pmrintro.aux) (/usr/share/texmf/tex/latex/cyrillic/ot2wncyr.fd)
(/usr/share/texmf/tex/latex/cyrillic/t2acmr.fd)
(/usr/share/texmf/tex/latex/base/ts1cmr.fd)       
-- 
Gary Stainburn
 
This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 
    

Re: Docbook on Mandrake 7.2/8.0

[Eric Bischoff]

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

Le Tuesday 22 May 2001 13:03, Gary Stainburn a écrit :
> Hi all,
>
> Here's my first line as it is in the document, and the first few lines
> of errors.  The second set is what happened when I changed it to look
> the same as the one in Docbook:TDG.
>
> <!doctype book PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
>
> [gary@gary revcom]$ db2pdf pmrintro.sgml
> Using stylesheet:
> "/usr/share/sgml/docbook/dsssl-stylesheets-cygnus/stylesheets/cygnus-both.d
>sl" jade:pmrintro.sgml:1:59:W: cannot generate system identifier for public
> text "-//Davenport//DTD DocBook V3.0//EN"

It does not recognize the type of your document. Which is not very 
surprising, DocBook 3.0 was already a production of OASIS, not Davenport 
anymore if I remember correctly.

> [gary@gary revcom]$ db2pdf pmrintro.sgml
> Using stylesheet:
> "/usr/share/sgml/docbook/dsssl-stylesheets-cygnus/stylesheets/cygnus-both.d
>sl" jade:E: cannot open
> "/usr/lib/sgml/stylesheets/nwalsh-modular/print/docbook.dsl" (No such
> file or directory)

Very strange that it looks for it in /usr/lib/sgml !

Perharps upgrade to a more recent Mandrake docbook style sheets package.

-- 
+----------------------------------------------------------------------+
| Éric Bischoff                              mailto:e.bischoff@noos.fr |
+----------------------------------------------------------------------+

Re: Docbook on Mandrake 7.2/8.0

[Gary Stainburn]

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

I have now cut/pasted example.sgml from the Docbook:TDG and tried to 
run db2df on it.

I get the errors:

[gary@gary revcom]$ db2pdf example.sgml
Using stylesheet: 
"/usr/share/sgml/docbook/dsssl-stylesheets-cygnus/stylesheets/cygnus-both.dsl"
jade:E: cannot open 
"/usr/lib/sgml/stylesheets/nwalsh-modular/print/docbook.dsl" (No such 
file or directory)
jade:E: specification document does not have the DSSSL architecture as 
a base architecture
This is pdfTeX, Version 3.14159-13d (Web2C 7.3.1)
(example.tex[/usr/share/texmf/pdftex/config/pdftex.cfg]
JadeTeX 2000/06/20: 2.20
(/usr/share/texmf/tex/latex/psnfss/t1ptm.fd)
Elements will be labelled
Jade begin document sequence at 2
(example.aux) (/usr/share/texmf/tex/latex/cyrillic/ot2wncyr.fd) 

This is because the directory /usr/lib/sgml/stylesheets does not have 
the nwalsh-modular directory in it. It only has 

iso-entities-8879.1986/ 

Presumably, I've got some rpms still missing.

can anyone help?

Gary

On Tuesday 22 May 2001 12:56 pm, Eric Bischoff wrote:
> Le Tuesday 22 May 2001 13:03, Gary Stainburn a écrit :
> > Hi all,
> >
> > Here's my first line as it is in the document, and the first few
> > lines of errors.  The second set is what happened when I changed it
> > to look the same as the one in Docbook:TDG.
> >
> > <!doctype book PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
> >
> > [gary@gary revcom]$ db2pdf pmrintro.sgml
> > Using stylesheet:
> > "/usr/share/sgml/docbook/dsssl-stylesheets-cygnus/stylesheets/cygnu
> >s-both.d sl" jade:pmrintro.sgml:1:59:W: cannot generate system
> > identifier for public text "-//Davenport//DTD DocBook V3.0//EN"
>
> It does not recognize the type of your document. Which is not very
> surprising, DocBook 3.0 was already a production of OASIS, not
> Davenport anymore if I remember correctly.
>
> > [gary@gary revcom]$ db2pdf pmrintro.sgml
> > Using stylesheet:
> > "/usr/share/sgml/docbook/dsssl-stylesheets-cygnus/stylesheets/cygnu
> >s-both.d sl" jade:E: cannot open
> > "/usr/lib/sgml/stylesheets/nwalsh-modular/print/docbook.dsl" (No
> > such file or directory)
>
> Very strange that it looks for it in /usr/lib/sgml !
>
> Perharps upgrade to a more recent Mandrake docbook style sheets
> package.

-- 
Gary Stainburn
 
This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 
    

Re: Docbook on Mandrake 7.2/8.0

[Eric Bischoff]

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

Le Thursday 24 May 2001 17:12, Gary Stainburn a écrit :
> I have now cut/pasted example.sgml from the Docbook:TDG and tried to
> run db2df on it.
>
> I get the errors:
>
> [gary@gary revcom]$ db2pdf example.sgml
> Using stylesheet:
> "/usr/share/sgml/docbook/dsssl-stylesheets-cygnus/stylesheets/cygnus-both.d
>sl" jade:E: cannot open
> "/usr/lib/sgml/stylesheets/nwalsh-modular/print/docbook.dsl" (No such
> file or directory)

/usr/lib is very strange in this context. There must be something broken in 
the Mandrake. Or you are mixing old and new setups. Please reinstall all 
docbook packages.


-- 
+----------------------------------------------------------------------+
| Éric Bischoff                              mailto:e.bischoff@noos.fr |
+----------------------------------------------------------------------+

HTML 2 DocBook tool

[Poet/Joshua Drake]

Hello,

We have just released our HTML 2 DocBook program. It is not free, but if
there are some people out there dying to convert the HTML to Docbook this
will help a great deal. The page includes example outputs.

You can find more information at http://www.commandprompt.com/products.lxp
. Just click on DocParse.

Joshua Drake
Poet
-- 
--
<COMPANY>CommandPrompt	- http://www.commandprompt.com	</COMPANY>
<PROJECT>OpenDocs, LLC.	- http://www.opendocs.org	</PROJECT>
<PROJECT>LinuxPorts 	- http://www.linuxports.com     </PROJECT>
<WEBMASTER>LDP		- http://www.linuxdoc.org	</WEBMASTER>
--
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.
--

Support for XML iso entities

[Eric Bischoff]

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

Hi all,

I just committed a new version of sgml-common which includes the XML version 
of the ISO entities, and a new version of the XML Docbook DTD version 4.1 
that uses these entities.

In the previous state, the XML Docbook DTD used the SGML entities. It worked 
with SGML tools like jade, but failed with XML tools like xalan.

So now we have

	/usr/share/sgml/
		sgml-iso-entities-8879.1986
		xml-iso-entities-8879.1986

As usually all the packages are available at
ftp://sourceware.cygnus.com/pub/docbook-tools/new-trials .

-- 
+----------------------------------------------------------------------+
| Éric Bischoff                              mailto:e.bischoff@noos.fr |
+----------------------------------------------------------------------+

Re: Support for XML iso entities

[Jorge Luiz Godoy Filho]

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

On Sat, 26 May 2001, e.bischoff@noos.fr wrote:
> Hi all,
> 
> I just committed a new version of sgml-common which includes the XML
> version of the ISO entities, and a new version of the XML Docbook
> DTD version 4.1 that uses these entities.
> 
> In the previous state, the XML Docbook DTD used the SGML
> entities. It worked with SGML tools like jade, but failed with XML
> tools like xalan.
> 
> So now we have
> 
> 	/usr/share/sgml/
> 		sgml-iso-entities-8879.1986
> 		xml-iso-entities-8879.1986
> 
> As usually all the packages are available at
> ftp://sourceware.cygnus.com/pub/docbook-tools/new-trials .

Please,

Don't do that. Instead create an xml-common. XML entities are not
required to proccess SGML documents and SGML entities aren't required
to proccess XML documents. 

I've created an xml-common package here and it's been working for a
while now. 


Be seeing you,
-- 
Godoy. <godoy@conectiva.com>

Suporte à Rede Conectiva de Serviços -- Conectiva Services Network Support
Conectiva S.A     -    www.conectiva.com.br     -   +55 (41) 360-2600
Conectiva Inc.    -    www.conectiva.com        -   +55 (41) 360-2600

Re: Support for XML iso entities

[Eric Bischoff]

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

Le Lundi 28 Mai 2001 14:34, Jorge Luiz Godoy Filho a écrit :
> Please,

Hi Jorge. I hope you are doing fine.

> Don't do that. Instead create an xml-common. XML entities are not
> required to proccess SGML documents and SGML entities aren't required
> to proccess XML documents.

But you can use SGML entities to process XML documents and XML entities to 
process SGML documents. There is interoperability.

> I've created an xml-common package here and it's been working for a
> while now.

-- 
Éric Bischoff  -  Documentation and Localization
Caldera (Deutschland) GmbH - Linux for eBusiness
Tel: +49 9131 7192 300 -  Fax: +49 9131 7192 399
http://www.caldera.de/

Re: Support for XML iso entities

[Jorge Luiz Godoy Filho]

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

On Mon, 28 May 2001, e.bischoff@noos.fr wrote:
> Le Lundi 28 Mai 2001 14:34, Jorge Luiz Godoy Filho a écrit :
>> Please,
> 
> Hi Jorge. I hope you are doing fine.

Hi! I'm OK, thanks. :-))

>> Don't do that. Instead create an xml-common. XML entities are not
>> required to proccess SGML documents and SGML entities aren't
>> required to proccess XML documents.
> 
> But you can use SGML entities to process XML documents and XML
> entities to process SGML documents. There is interoperability.

So, why copying them again? ;-) There are difference on some
characters representations. See, e.g., á:

SGML entities:

<!ENTITY aacute SDATA "[aacute]"--=small a, acute accent-->

XML entities:

<!ENTITY aacute "&#x00E1;"> <!-- LATIN SMALL LETTER A WITH ACUTE -->



For XML entities one uses Unicode representation, for SGML not.



Be seeing you,
-- 
Godoy. <godoy@conectiva.com>

Suporte à Rede Conectiva de Serviços -- Conectiva Services Network Support
Conectiva S.A     -    www.conectiva.com.br     -   +55 (41) 360-2600
Conectiva Inc.    -    www.conectiva.com        -   +55 (41) 360-2600

Re: Support for XML iso entities

[Eric Bischoff]

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

Le Mardi 29 Mai 2001 01:29, Jorge Luiz Godoy Filho a écrit :
> > Hi Jorge. I hope you are doing fine.
>
> Hi! I'm OK, thanks. :-))

Super! :-)

> >> Don't do that. Instead create an xml-common. XML entities are not
> >> required to proccess SGML documents and SGML entities aren't
> >> required to proccess XML documents.
> >
> > But you can use SGML entities to process XML documents and XML
> > entities to process SGML documents. There is interoperability.
>
> (...) For XML entities one uses Unicode representation, for SGML not.

I know. But XML files are SGML files (the contrary is not true) and SGML 
tools can use both entity sets. I'm not sure however that it would mean that 
we can get rid of the SGML-only version of the ISO entities, they way they 
are declared could have some impact, for example on stylesheets.

I've simply been putting everything together because of this 
interoperability, and to avoid multiplying the number of packages. Don't you 
think we've got already enough of them? ;-)

I agree that a separate xml-common package could be a valid technical 
solution, I just don't really see a good reason why we should go this way. 

Everything this package contains are very basic and small ressources, 
although a bit heterogeneous. I think that both versions of the ISO entities 
go well together in this package.

-- 
Éric Bischoff  -  Documentation and Localization
Caldera (Deutschland) GmbH - Linux for eBusiness
Tel: +49 9131 7192 300 -  Fax: +49 9131 7192 399
http://www.caldera.de/

Re: Support for XML iso entities

[Jorge Luiz Godoy Filho]

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

On Tue, 29 May 2001, e.bischoff@noos.fr wrote:
> Le Mardi 29 Mai 2001 01:29, Jorge Luiz Godoy Filho a écrit :
>> > Hi Jorge. I hope you are doing fine.
>>
>> Hi! I'm OK, thanks. :-))
> 
> Super! :-)

Thanks! And how about you? Too much work?

>> (...) For XML entities one uses Unicode representation, for SGML
>> not.
> 
> I know. But XML files are SGML files (the contrary is not true) and
> SGML tools can use both entity sets. I'm not sure however that it
> would mean that we can get rid of the SGML-only version of the ISO
> entities, they way they are declared could have some impact, for
> example on stylesheets.
> 
> I've simply been putting everything together because of this
> interoperability, and to avoid multiplying the number of
> packages. Don't you think we've got already enough of them? ;-)

No, I don't. As a base package for SGML processing, I think it should
be only for SGML processing. Without caring for what tool can or
cannot use it. If the specs says that we should use those entities in
some specific way, that's what we should go for. 

XML specs says that entities must be specified in Unicode. So, the
specs requires different things. Besides, I don't see any problem
having a package with only XML entities (and that package might
requires sgml-common, for the catalog installation and other tools). 

> I agree that a separate xml-common package could be a valid
> technical solution, I just don't really see a good reason why we
> should go this way.

The reason is: having fewer things, makes you worry with fewer
problems. And (I know disk is cheap) it will make our packages smaller
and more specific to a desired function. 

> Everything this package contains are very basic and small
> ressources, although a bit heterogeneous. I think that both versions
> of the ISO entities go well together in this package.

I still think that there should be an xml-common. BUT, I don't want to
push you to this decision. I just want, if it will be in the same
package, to be able to split them here and have all the tools
working. There should be no requirement os assumption on any of the
tools that I will always have both XML and SGML stuff together since
this isn't true. People get really lost with this complex system and
all this catalog and entities stuff... Having unused stuff installed
there will make them even more confused.


As I saida, this is only my opinion. If you decide not to take it,
I'll accept and keep on using the packages. :-) 


Be seeing you,
-- 
Godoy. <godoy@conectiva.com>

Suporte à Rede Conectiva de Serviços -- Conectiva Services Network Support
Conectiva S.A     -    www.conectiva.com.br     -   +55 (41) 360-2600
Conectiva Inc.    -    www.conectiva.com        -   +55 (41) 360-2600

Tex Capacity Exceeded (was Docbook on Mandrake 7.2/8.0)

[Gary Stainburn]

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

Hi all,

Having failed abismally to get db working on MDK7 I've gone back to a 
RH6.2 system and installed the rpms.

When I try to run db2pdf I get the following error.  Anyone got any 
ideas?

__BEGIN__
[gary@dcomp2 gary]$ db2pdf pmrintro.sgml
This is pdfTeX, Version 3.14159-13d (Web2C 7.3.1)
(pmrintro.tex[/usr/share/texmf/pdftex/config/pdftex.cfg]
JadeTeX 1999/06/29: 2.7
(/usr/share/texmf/tex/latex/psnfss/t1ptm.fd)
(/usr/share/texmf/tex/jadetex/isoents.tex
! TeX capacity exceeded, sorry [hash size=10000].
l.1417 \expandafter\def\csname EntnvDash\endcsname
                                                  
{\ensuremath{\nvDash}}% U2...
 
!  ==> Fatal error occurred, the output PDF file not finished!
Transcript written on pmrintro.log.
[gary@dcomp2 gary]$
__END__

On Thursday 24 May 2001  6:29 pm, Eric Bischoff wrote:
> Le Thursday 24 May 2001 17:12, Gary Stainburn a écrit :
> > I have now cut/pasted example.sgml from the Docbook:TDG and tried
> > to run db2df on it.
> >
> > I get the errors:
> >
> > [gary@gary revcom]$ db2pdf example.sgml
> > Using stylesheet:
> > "/usr/share/sgml/docbook/dsssl-stylesheets-cygnus/stylesheets/cygnu
> >s-both.d sl" jade:E: cannot open
> > "/usr/lib/sgml/stylesheets/nwalsh-modular/print/docbook.dsl" (No
> > such file or directory)
>
> /usr/lib is very strange in this context. There must be something
> broken in the Mandrake. Or you are mixing old and new setups. Please
> reinstall all docbook packages.

-- 
Gary Stainburn
 
This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 
    

Re: Tex Capacity Exceeded (was Docbook on Mandrake 7.2/8.0)

[Eric Bischoff]

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

Le Mercredi 30 Mai 2001 13:33, Gary Stainburn a écrit :
> Hi all,
>
> Having failed abismally to get db working on MDK7 I've gone back to a
> RH6.2 system and installed the rpms.
>
> When I try to run db2pdf I get the following error.  Anyone got any
> ideas?
> (...)
> ! TeX capacity exceeded, sorry [hash size=10000].
> (...)

Increase the hash size in the f***ing texmf.cnf file.

TeX s***ks.

Re: Tex Capacity Exceeded (was Docbook on Mandrake 7.2/8.0)

[Gary Stainburn]

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

Hi Eric, all,

I had sussed that, but the problem was that the texmf.cnf was 459 lines 
long, and the error msg didn't give a good pointer to which value to 
change.

Anyways, I've go a bit further - I now get the following displayed.  
The errors extend to quite a number of occurrences.  I have absolutely 
no idea where to go next as I was in over my head quite a while back.

Gary

__BEGIN__
[gary@dcomp2 revcom]$ db2pdf pmrintro.sgml
This is pdfTeX, Version 3.14159-13d (Web2C 7.3.1)
(pmrintro.tex[/usr/share/texmf/pdftex/config/pdftex.cfg]
JadeTeX 1999/06/29: 2.7
(/usr/share/texmf/tex/latex/psnfss/t1ptm.fd)
(/usr/share/texmf/tex/jadetex/isoents.tex)
Elements will be labelled
Jade begin document sequence at 20
(pmrintro.aux) (/usr/share/texmf/tex/latex/ot2cyr/ot2wncyr.fd)
(/usr/share/texmf/tex/latex/base/ts1cmr.fd)
(/usr/share/texmf/tex/latex/lucidabr/lmrhlcm.fd)
(/usr/share/texmf/tex/context/base/supp-pdf.tex
(/usr/share/texmf/tex/context/base/supp-mis.tex
loading : Context Support Macros / Missing
)
loading : Context Support Macros / PDF
) (/usr/share/texmf/tex/latex/psnfss/t1phv.fd) 
[1.0.21[/usr/share/texmf/dvips/config/pdftex.map]] [2.0.21] [3.0.21] 
[4.0.21] [5.0.21] [6.0.21]
! Text line contains an invalid character.
l.3543 {^^@
           ^^@}\def\sbNom%
! Text line contains an invalid character.
l.3543 {^^@^^@
              }\def\sbNom%
! Text line contains an invalid character.
l.3565 {^^@
           ^^@}\def\sbNom%
! Text line contains an invalid character.A
__END__

On Wednesday 30 May 2001  1:35 pm, Eric Bischoff wrote:
> Le Mercredi 30 Mai 2001 13:33, Gary Stainburn a écrit :
> > Hi all,
> >
> > Having failed abismally to get db working on MDK7 I've gone back to
> > a RH6.2 system and installed the rpms.
> >
> > When I try to run db2pdf I get the following error.  Anyone got any
> > ideas?
> > (...)
> > ! TeX capacity exceeded, sorry [hash size=10000].
> > (...)
>
> Increase the hash size in the f***ing texmf.cnf file.
>
> TeX s***ks.

-- 
Gary Stainburn
 
This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 
    

Re: Support for XML iso entities

[Eric Bischoff]

On Tuesday 29 May 2001 15:22, Jorge Luiz Godoy Filho wrote:
> >> > Hi Jorge. I hope you are doing fine.
> >>
> >> Hi! I'm OK, thanks. :-))
> >
> > Super! :-)
>
> Thanks! And how about you? Too much work?

As you can say with the date of this reply, yes :-(.

> > I've simply been putting everything together because of this
> > interoperability, and to avoid multiplying the number of
> > packages. Don't you think we've got already enough of them? ;-)
>
> No, I don't. As a base package for SGML processing, I think it should
> be only for SGML processing. Without caring for what tool can or
> cannot use it. If the specs says that we should use those entities in
> some specific way, that's what we should go for.

The problem is that XML processing is SGML processing.

> XML specs says that entities must be specified in Unicode. So, the
> specs requires different things. Besides, I don't see any problem
> having a package with only XML entities (and that package might
> requires sgml-common, for the catalog installation and other tools).

I don't see any problem with having only one package either.

> > I agree that a separate xml-common package could be a valid
> > technical solution, I just don't really see a good reason why we
> > should go this way.
>
> The reason is: having fewer things, makes you worry with fewer
> problems. And (I know disk is cheap) it will make our packages smaller
> and more specific to a desired function.

Come on... sgml-common is ridiculously small, and now you want to split it 
again...

> > Everything this package contains are very basic and small
> > ressources, although a bit heterogeneous. I think that both versions
> > of the ISO entities go well together in this package.
>
> I still think that there should be an xml-common. BUT, I don't want to
> push you to this decision. I just want, if it will be in the same
> package, to be able to split them here and have all the tools
> working. There should be no requirement os assumption on any of the
> tools that I will always have both XML and SGML stuff together since
> this isn't true. People get really lost with this complex system and
> all this catalog and entities stuff... Having unused stuff installed
> there will make them even more confused.

Having too much packages doesn't help a lot with respect to complexity either.

> As I saida, this is only my opinion. If you decide not to take it,
> I'll accept and keep on using the packages. :-)

I'm no dictator ;-). I need to speak about this with Mark Galassi. A lot of 
people seem to (unfortunately ;-) ) agree with you.

Sad you didn't make it to go to San Diego. We could have met.

Re: Support for XML iso entities

[Jorge Godoy]

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

Eric Bischoff <e.bischoff@noos.fr> writes:

>> > I've simply been putting everything together because of this
>> > interoperability, and to avoid multiplying the number of
>> > packages. Don't you think we've got already enough of them? ;-)
>>
>> No, I don't. As a base package for SGML processing, I think it should
>> be only for SGML processing. Without caring for what tool can or
>> cannot use it. If the specs says that we should use those entities in
>> some specific way, that's what we should go for.
> 
> The problem is that XML processing is SGML processing.

This is true if we think only about the specs of how to write
documents. XML supports namespaces and other stuff that might become
more and more complex. 

I am still for having a separate package form SGML entities and one
for XML entities. 

>> XML specs says that entities must be specified in Unicode. So, the
>> specs requires different things. Besides, I don't see any problem
>> having a package with only XML entities (and that package might
>> requires sgml-common, for the catalog installation and other tools).
> 
> I don't see any problem with having only one package either.

Disk space with things that will *never* be used, more configuration
required in each package to make both confs work. 

These are problems that requires more knowledgement from the packager
and make thinks more susceptible to mistakes. 

>> > I agree that a separate xml-common package could be a valid
>> > technical solution, I just don't really see a good reason why we
>> > should go this way.
>>
>> The reason is: having fewer things, makes you worry with fewer
>> problems. And (I know disk is cheap) it will make our packages smaller
>> and more specific to a desired function.
> 
> Come on... sgml-common is ridiculously small, and now you want to split it 
> again...

Yep. :o)
In fact, I already have done it. 


Name        : sgml-common                  Relocations: (not relocateable)
Version     : 0.2                               Vendor: Conectiva
Release     : 7cl                           Build Date: Ter 23 Jan 2001 12:36:10 BRST
Install date: Qua 25 Jul 2001 19:58:50 BRT      Build Host: mapi2.distro.conectiva
Group       : Text                          Source RPM: sgml-common-0.2-7cl.src.rpm
Size        : 123043                           License: GPL


and

Name        : xml-common                   Relocations: (not relocateable)
Version     : 0.1                               Vendor: Conectiva
Release     : 5cl                           Build Date: Seg 15 Jan 2001 14:54:27 BRST
Install date: Qua 25 Jul 2001 19:58:51 BRT      Build Host: mapi2.distro.conectiva
Group       : Text                          Source RPM: xml-common-0.1-5cl.src.rpm
Size        : 63816                            License: GPL


As you can see, xml-common is bigger than half of sgml-common. It
makes it interesting to have a new package. 


> Having too much packages doesn't help a lot with respect to complexity either.

It makes things more specific and allows one to have installed only
what's needed. 

With the two packages above, I'd have to have 3 times more disk space
than what I'll be really using if I'd have to worry only with XML. 

This is not a problem for big systems, but it starts to be with
embedded systems. Lets keep things small and specific so that we won't
need to discuss it all over again in the future. 

> I'm no dictator ;-). I need to speak about this with Mark Galassi. A lot of 
> people seem to (unfortunately ;-) ) agree with you.

Good! :o)) 

> Sad you didn't make it to go to San Diego. We could have met.

Indeed :-(
We are with lots of things here... And I'm writing several documents
now, while also developing some stylesheets to our books and internal
documents. 

Creating specialized DTDs is also funny :o)



-- 
Godoy. <godoy@conectiva.com>

Solutions Developer       - Conectiva Inc. - http://www.conectiva.com
Desenvolvedor de Soluções - Conectiva S.A. - http://www.conectiva.com.br

RE: Support for XML iso entities

[Peter Ring]

I'm absolutely in favour of keeping character entity packages for XML and
SGML separate. 

I don't care much for disk space conservation, but I don't like to introduce
artificial dependencies. XML proccessing tools won't grok SDATA. And some
SGML processing tools don't grok hex numerical character references, and
besides need an SGML declaration for XML. So why make the release of one set
of features dependent on the other?

kind regards,
Peter Ring

BTW, there's a dirty trick for 'portable' character entity declarations at
http://lists.oasis-open.org/archives/docbook/199911/msg00005.html . I didn't
tell you.