Re: [xml] Modules and APIs for LSB

[Daniel Veillard <veillard redhat com>]

On Thu, Dec 22, 2005 at 11:30:03AM -0800, Banginwar, Rajesh wrote:
> Hi Daniel,
> 	I will like to confirm some of things for LSB inclusion. You
> have indicated this in your earlier emails, but I thought I should
> summarize here for confirmation etc...
> 
> Here is the summary of what is excluded from LSB:
> 
> libxml2 has 47 different sub modules. Most of the modules are used by
> applications, except a few which are either deprecated or internal. The
> following modules should not be included into the LSB specification: 
> * DOCBparser - deprecated 
> * SAX - deprecated 
> * schemasInternals - not stable enough to be included 
> * XLink - unfinished and not stable 
> * xmlunicode - low-level; should not be used externally but interface is
> public 
> * chvalid - low-level; should not be used externally but interface is
> public 
> * nanohttp - low-level; should not be used externally but interface is
> public 
> * nanoftp - low-level; should not be used externally but interface is
> public 

  Yes, sound fine

> The following functions should not be included: 
> 
> HTMLparser :htmlNodeStatus - Experimental 
> 
> catalog :xmlCatalogGetSystem, xmlCatalogGetPublic - deprecated 
> 
> entities: xmlCleanupPredefinedEntities, xmlCreateEntitiesTable,
> xmlInitializePredefinedEntities, xmlEncodeEntities - deprecated 
> 
> parser: xmlGetFeature, xmlGetFeaturesList, xmlSetFeature - deprecated 
> 
> parserInternals: xmlCheckLanguageID, xmlDecodeEntities, xmlHandleEntity,
> xmlNamespaceParseNCName, xmlNamespaceParseNSDef, xmlNamespaceParseQName,
> xmlParseNamespace, xmlParseQuotedString, xmlParserHandleReference,
> xmlScanName - deprecated 
> 
> tree: xmlDOMWrapRemoveNode, xmlDOMWrapReconcileNamespaces,
> xmlDOMWrapAdoptNode  - Experimental 
> 
> tree: xmlNewGlobalNs - deprecated 
> 
> valid: xmlCopyElementContent,
> xmlFreeElementContent,xmlNewElementContent, xmlSprintfElementContent -
> deprecated 

  yes looks right

> Same information can be found on LSB Wiki at:
> http://www.linuxbase.org/LSBWiki/LibXml2
> 
> Can you please confirm this?

  yes looks good !

> Also, if nanoHTTP/Ftp is not included, what is the alternative for
> application developers? I did see some of the APIs wrapped by xmlIO
> interfaces but not all (e.g. ScanProxy). Is that correct?

  It should not be included as an API but compiled in nonetheless so that
the library can use ftp:// and http:// URIs.
  People needing more advanced URI handlers usually end up using curl with
libxml2 (https, athentication, etc...)
  Other interfaces like curl or custom handlers can be plugged with
  http://xmlsoft.org/html/libxml-xmlIO.html#xmlRegisterInputCallbacks
     xmlRegisterInputCallbacks()
and  xmlRegisterOutputCallbacks()
they are in the xmlIO module, that's right.

> Also, I will like to find out whether following types are really
> required by application developers (and hence should they be in LSB?). 
> 
> attributeSAXFunc 

  This was never made a standalon callback so yes that can be dropped

> htmlParserInputPtr 

  identical to an xmlParserInputPtr but for the HTML parser

> htmlParserNodeInfo
  
  idem, but can probably be dropped as it is not frequently used

> xmlSAXHandlerV1Ptr 

  Hum, some apps may still be using the SAX1 APIs, on the other hand
SAX.h is not included. it's on the edge, hard to tell

> xmlSchematronValidityErrorFunc
> xmlSchematronValidityWarningFunc

  if the schematron module is included then they should be kept.

> xmlValidStatePtr

  probably doesn't need to be exposed

> xmlXPathVariablePtr 

  I would keep it, this is part of the XPath model.

> htmlElemDescPtr, htmlEntityDescPtr, htmlParserInput

  htmlParserInput is an alias for an xmlParserInput, keep.
  
  The public functions htmlTagLookup and htmlEntityLookup returns
htmlElemDescPtr, and htmlEntityDescPtr, or rather their struct pointer form,
yes I would keep those.

> xmlShellCmd

  That would be used for people using the pluggable shell debug interface.
I think I know 2 developpers who use it, I would keep it.

> xmlXPathEvalFunc
> xmlXPathFuncPtr

  I would keep those two, yes.

> 
> Please let me know whether these types are required for app developers
> as I could not find them used by any interfaces etc. Once confirmed, I

  probably because they are aliases for other types mostly.

> will updated LSB spec.

  okay, thanks !

> Sorry for rather long email... 

  no problem !

> PS. I will send out email here again in few days announcing availability
> of LSB Desktop spec once I update the libxml2 spec based on your
> response to this email.

  Cool, thanks a lot !

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/