Re: XML idea

[richard]

On 6 Jan 2004, at 22:40, Alex Perez wrote:

> On Tue, 6 Jan 2004, Helge Hess wrote:
>
> > On 06.01.2004, at 22:29, Alex Perez wrote:
> > > This is exactly what I was referring to. I think you misunderstood
> > > what I
> > > meant. the GNUstep team has a policy of keeping XML stuff out of (or 
> > > at
> > > least totally optional in) GNUstep-base.
> >
> > I don't think that this is still valid. I guess the policy is to keep
> > *GSXML* out of gstep-base (though this is the first time I hear of 
> > such
> > a policy), having NSXMLParser in Cocoa Foundation obviously changes
> > that.
> The official word, AFAIK, is that XML stuff in general is to be kept 
> out
> of base, except on an OPTIONAL basis, which is how it is now. It's not
> just GSXML.

A quick explanation here might help.
The base cvs package can be thought of as two parts ... a core set of 
classes
implementing common OpenStep/MacOS--X functionality and an additional
set of classes providing extra GNUstep specific functionality and some 
MacOS-X
compatibility features.  The core code is in the Source directory, with 
the
additional stuff in the Source/Additions directory.
This can be built in two ways -
1. The standard build incorporates the additional stuff into the base 
library ...
so the features in the additions are always present in the base library.
2. The additions can be built as a standalone library and the base 
library
is not built ... so the additions can be used without the base library..

So ... the XML stuff (part of the additions) is built in either case - 
you can get
additions without base, but not base without additions.

> > At least I would be surprised if Adam, Richard or Nicola would be
> > against adding NSXMLParser to gstep-base.
> > +5 from me, don't want to work against three different Foundation APIs
> > ;-)
> It could be put there, but it would only be a class that worked if
> --with-xml or whatever were used, same as how GSXML works now.

The base/additions library builds with xml unless you explictly tell it 
not to.