Re: [xml] RE: XML modules and interface

[Daniel Veillard <veillard redhat com>]

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/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/