Re: [xml] RE: XML modules and interface

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

  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

  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

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


Daniel Veillard      | Red Hat Desktop team
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]