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
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/



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