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

Reply via email to