RE: Support for XML iso entities

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.

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

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

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

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