[xml] 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/



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