On Thu, Sep 29, 2005 at 06:05:25PM -0700, Jain, Nilesh wrote: > 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.
That was understood, I knew that in replying. > 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. Understood too. > Keeping that thing in mind do you think validation/internal/debugging > API should be used by application.. validation definitely is part of the application API needs, SAX too, those there is no doubt at all about it, if you drop them the resulting subset won't be interesting for a lot of application, I mean business applications, the ones which need the LSB and produced by third parties. Internal is a problem in the sense that some of those API may be important for applications. It may be a case by case basis Debugging (xmlmemory.h/debugXML.h) is not a clear cut either, things like the shell interface of xmllint use that API. list/hash/dict are needed in the sense that sometimes they are exposed directly to the user, especially dict for string interning to a (set of) documents is important memory wise. > Reason for removing deprecated is that going forward they should not be > used, so there is no point in putting in standards. Definitely, that I have not trouble with. Some of the low level API like xmlunicode, chvalid, nanohttp and nanoftp could be excluded on the other hand, they are modules which I expect only libxml2 to call in general. > I hope I am clear enough. I know it's kind of hard, libxml2 API is very large and in practice providing high level APIs for XML is hard because there is a huge variability of uses can constraints in real applications. If it was just loading a config file default that would be less than 100KB even with full XML compliance, but there is an ecosystem of XML related specifications, not just parsing, and real business use are very very different, the trade off in term of speed, memory usage, and high level standards cannot be reduced in a limited set of APIs, that's why we have SAX, reader and DOM just as parser interfaces, and similary as much variety in the upper layers. The volume of printed documentation associated to the various specs implemented by libxml2 is probably more than 5cm thick when piled together and they are not defined in terms of APIs, this is a complex software toolkit... 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
