Re: [xml] LSB specification for libxml2 library

[Daniel Veillard <veillard redhat com>]

On Mon, Jan 02, 2006 at 03:53:38PM -0800, Banginwar, Rajesh wrote:
> Hi,
>       Please find the LSB specification for libxml2 library at
> http://www.linuxbase.org/spec//book/XML/XML.html. 
>
> The plan is to have a separate module for XML. For the time being,
> libxml2 library will part of LSB desktop specification. In LSB 4.0
> timeframe (early 2007), it will become part of both Server and Desktop
> certification programs.
>
> Please review the specification, and send feedback. Feedback can be sent
> here on this mailing list or on lsb-desktop mailing or preferably at
> bugs.linuxbase.org.
>
> Kindly tell us about the organization of different segments of libxml2.
> The organization is slightly different than the libxml2 documentation.

  Hum, the reorganization of the headers will raise some confusion
xmlParserErrors is now in parser.h , while it covers all errors reporting
from the library. It also looses all comments related to the functions
and data. I wonder how people are supposed to use this, libxml2 API is
huge, and the existing doc is already considered hard to grasp, but without
any comment, and just the dump of the identifiers I wonder what's the intent
of this document, how are people supposed to use it ?

  The only pointer to xmlsoft.org is a normative reference but it describes
libxml2 upstream information, with a different set of headers, how can this
be normative too if different ? One frequent question here is how to capture
and handle errors in the toolkit, and the canonical answer is to point to the
error.h header defining the functions, data and constants needed to process
those, but this header don't exist in your list, and I'm not sure all the
data it exposes are also available.

  Nothing new, I'm worried by the changes made to the headers, and how the
users are supposed to deal with two distinctive version. The fork generated
doesn't seems in my opinion to be in the users best interest, the side effects
being either confusion, or wasted efforts depending on how much traction the
LSB variant will get. It's hard to predict how useful it will be and I would
have preferred to be more enthusisatic about the LSB endorsement.

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/