[xml] RE: XML modules and interface

["Jain, Nilesh" <nilesh jain intel com>]

I think I wasn't clear enough about rational and implication. First of
all not including a API in specification doesn't mean excluding from the
library. 

Rational used to include a API into specification is that the API should
be stable, defined for application/user and it is a best practice. Which
mean specification is usually a sub set of all public interfaces in a
library. 

Keeping that thing in mind do you think validation/internal/debugging
API should be used by application.. 

Reason for removing deprecated is that going forward they should not be
used, so there is no point in putting in standards. 

I hope I am clear enough. 

Thanks,
Nilesh 

> -----Original Message-----
> From: Daniel Veillard [mailto:veillard redhat com]
> Sent: Thursday, September 29, 2005 4:59 PM
> To: Jain, Nilesh
> Cc: xml gnome org
> Subject: Re: XML modules and interface
>
> On Thu, Sep 29, 2005 at 04:40:32PM -0700, Jain, Nilesh wrote:
> > I am going through the APIs and modules listed on the website to
include
> > into LSB specification.
> >
> > I have identified some modules which I think should not be included
into
> > the LSB specification because they are not meant for an application.
> > Below is the list of such module along with brief reason. I would
really
> > appreciate your feedback on my analysis or if you think something
should
> > be included because it is supposed to be used by application.. please
> > also point out if I missed something which should not included.
> >
> > DOCBparser - Deprecated
> > SAX - Deprecated
>
> no !
>
>  SAX1 is kind of deprecated, but still used by a number of apps
>  SAX2 is a very important parser interface must be kept
>
> > parserInternals - internal routine
>
> no
>  Some of them are needed for advanced parsing use
>
> > hash - internal
>
>  but public API
>
> > list - internal
>
>  but public API
>
> > pattern - for validation
>
> no
>  also used for streaming search of path I don't see why this should
>  be dropped this is important for performance oriented processing of
>  streams
>
> > relaxng - for validation
>
> no
>  validation *is* important
>
> > schemasInternals -for validation
>
>  not stable enough, so drop
>
> > schematron - for validation
>
> no
>  validation *is* important
>
> > valid - for DTD validation
>
> no
>  validation *is* important
>
> > XLink - unfinished/???
>
> yes
>  drop
>
> > xmlIO - seems internal module
>
> tentatively no
>  needed to register new I/O hooks like curl
>
> > xmlmemory - memory allocator (seems internal module)
>
>  also needed for debug
>
> > xmlregexp - seems internal module
>
> yes and no
>  I could see this used by other parts
>
> > xmlschemas - incomplete
>
> no
>  only one feature missing. very important to be kept !
>
> > xmlschemastypes - internal
>
> no
>  XML Schemas type are important for anybody doing validation
>  or using recent W3C XML specs
>
> > xpathInternals - internal
>
> no
>  internal to some extents only needed by libxslt
>
> > debugXML - Debugging APIs
>
>  debugging but stable.
>
> I think you are dropping a lot of things which are really important,
> a lot of them are what makes the difference between libxml2
> and a library like expat which just does XML parsing and generate an
> event stream. By doing so there is then very limited advantages over
> a very limited library.
> For example xmlsec1 and libxslt libraries which implement
> XML Digital signatures and XSLT-1.0 on top of libxml2 just would not
> work at all on top of your subset, and those are shipped too as basic
> XML tools on the distros.
> Removing the various validation APIs from libxml2 would also be a
complete
> nonsense to me.
>
> Daniel
>
>
> --
> Daniel Veillard      | Red Hat Desktop team http://redhat.com/
> veillard redhat com  | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/