public inbox for
 help / color / mirror / Atom feed
From: Jorge Godoy <>
To: Eric Bischoff <>
Cc: <>
Subject: Re: Support for XML iso entities
Date: Sun, 12 Aug 2001 15:39:00 -0000	[thread overview]
Message-ID: <m3g0ax4gio.fsf@dagon.conectiva> (raw)
In-Reply-To: <>

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

Eric Bischoff <> 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


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

Creating specialized DTDs is also funny :o)

Godoy. <>

Solutions Developer       - Conectiva Inc. -
Desenvolvedor de Soluções - Conectiva S.A. -

  reply	other threads:[~2001-08-12 15:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-22  4:08 Docbook on Mandrake 7.2/8.0 Gary Stainburn
2001-05-22  4:55 ` Eric Bischoff
2001-05-24  8:16   ` Gary Stainburn
2001-05-24 10:28     ` Eric Bischoff
2001-05-25 17:08       ` HTML 2 DocBook tool Poet/Joshua Drake
2001-05-26  0:04         ` Support for XML iso entities Eric Bischoff
2001-05-28  5:31           ` Jorge Luiz Godoy Filho
2001-05-28  9:24             ` Eric Bischoff
2001-05-28 16:25               ` Jorge Luiz Godoy Filho
2001-05-29  1:47                 ` Eric Bischoff
2001-05-29  6:19                   ` Jorge Luiz Godoy Filho
2001-07-27 18:51                     ` Eric Bischoff
2001-08-12 15:39                       ` Jorge Godoy [this message]
2001-05-30  4:37       ` Tex Capacity Exceeded (was Docbook on Mandrake 7.2/8.0) Gary Stainburn
2001-05-30  5:28         ` Eric Bischoff
2001-05-30  7:33           ` Gary Stainburn
2001-08-15  2:38 Support for XML iso entities Peter Ring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3g0ax4gio.fsf@dagon.conectiva \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).