Re: [xml] Modules and APIs for LSB

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
* chvalid - low-level; should not be used externally but interface is
* nanohttp - low-level; should not be used externally but interface is
* nanoftp - low-level; should not be used externally but interface is

  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 -

  yes looks right

Same information can be found on LSB Wiki at:

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
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?). 


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


  identical to an xmlParserInputPtr but for the HTML parser

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


  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


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


  probably doesn't need to be exposed


  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.


  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.


  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 Veillard      | Red Hat
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]