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:[EMAIL PROTECTED] >Sent: Thursday, September 29, 2005 4:59 PM >To: Jain, Nilesh >Cc: [email protected] >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/ >[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ >http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
