RE: [xml] LSB specification for libxml2 library

-----Original Message-----
From: Daniel Veillard [mailto:veillard redhat com]
Sent: Tuesday, January 03, 2006 12:48 AM
To: Banginwar, Rajesh
Cc: xml gnome org
Subject: Re: [xml] LSB specification for libxml2 library

On Mon, Jan 02, 2006 at 03:53:38PM -0800, Banginwar, Rajesh wrote:
    Please find the LSB specification for libxml2 library at

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
certification programs.

Please review the specification, and send feedback. Feedback can be
here on this mailing list or on lsb-desktop mailing or preferably at

Kindly tell us about the organization of different segments of
The organization is slightly different than the libxml2

  Hum, the reorganization of the headers will raise some confusion
xmlParserErrors is now in parser.h , while it covers all errors
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
any comment, and just the dump of the identifiers I wonder what's the
of this document, how are people supposed to use it ?

The goal for LSB is not to provide the reference documentation to user.
LSB relies on upstream for that. In case there is no upstream reference
documentation, LSB tries to provide that. E.g. libpng12 library in

The specification documents the data definitions for a given library for
standardization; and the tools and tests are developed to confirm that.
E.g. lsblibchk tool tests for all exported symbols for a given runtime;
the tests that we took from libxml2 upstream will be used to test the
runtime semantic behavior.

Given LSB infrastructure, we tried to keep the organization of headers
intact (e.g. we moved xmlParserErrors to xmlerror.h), but failed in few
cases. As a check, we ported few applications like xlog, raptor etc. to
these new headers without too many problems. 

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

I think you meant xmlerror.h and it is in the spec. 

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

Next few months, we will have the specification reviewed and used by
some of the application developers. The only reason we are creating
these new headers is because not everything in libxml2 is in LSB. I
would have loved to keep the organization of headers intact for the part
that is in LSB. But it was not possible to do so as all headers are
auto-generated from a mysql database (which contains all symbol and type
info). The DB provides the central repository that we use for all our
tools (including headers etc).

If this turns out to be a bad thing (as you fear) for users, for LSB4.0
timeframe, we will need to find a different solution and avoid these LSB
specific headers.



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