Re: Support for XML iso entities

[Jorge Godoy <godoy@conectiva.com>]

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