From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jorge Godoy To: Eric Bischoff Cc: Subject: Re: Support for XML iso entities Date: Sun, 12 Aug 2001 15:39:00 -0000 Message-id: References: <01052910534905.01734@boson.caldera.de> <01072522365503.01176@grumble.caldera.de> X-SW-Source: 2001-q3/msg00026.html 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 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. Solutions Developer - Conectiva Inc. - http://www.conectiva.com Desenvolvedor de Soluções - Conectiva S.A. - http://www.conectiva.com.br