RE: [xml] LSB specification for libxml2 library

["Banginwar, Rajesh" <rajesh banginwar intel com>]

> -----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:
> > 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 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
LSB-Desktop.

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

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

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.

Thanks,

-Rajesh