RE: [xml] LSB specification for libxml2 library

Ok, I think I need to clarify here. 

The only patches we have for the ported application is to remove the
deprecated, internal interfaces or the ones that are not in LSB. E.g.
raptor is using nanoHTTP interfaces that we need to change. The patch is
not for headers or includes. For an application to become LSB compliant
we typically find such a need. Most of the time, the usage of deprecated
symbols (and the ones not included in LSB for some reason) need to be
replaced. Same case for libxml2.

And another clarification regarding fixing in 4.0:
I did not mean that we will change the standard, but just its
organization. If the feedback is LSB provided headers are bad or
incomplete or just not good for whatever reason, we can always go back
to upstream headers without really changing the standard. All we will be
doing is reorganizing it. 

We always have the option of specifying all interfaces, types and
#defines in a single section without any organization. This is as far as
the spec is concerned. Again, this is not changing the spec, but just
reorganizing it. In this case, LSB will just recommend using upstream
headers. The problem here is what I mentioned in my earlier email: How
do we tell developers to avoid certain things (types, #defines and
symbols) during their development?

There is even another option: Keep the spec as it is now and still
supply upstream headers to application developers. That way spec will
remain organized, but there will be no "fork" for the headers. We still
have the problem of "modifying" the upstream headers to hide the non-lsb
symbols and types.

Anyway, I do not want to alienate upstream by standardizing the
concerned library. That is really the last thing we will do. The only
reason LSB desktop project is interested in libxml2 is because it really
has become the best practice and we just like to formalize/endorse it.
The intentions have not changed since our discussion during OLS last

Thanks for your help and feedback.


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

On Wed, Jan 04, 2006 at 06:21:08PM -0800, Banginwar, Rajesh wrote:
Given LSB infrastructure, we tried to keep the organization of
intact (e.g. we moved xmlParserErrors to xmlerror.h), but failed in
cases. As a check, we ported few applications like xlog, raptor etc.
these new headers without too many problems.

  Ideally there should be no inclusion problem, we will see ...

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

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

  okay I missed that.

  Nothing new, I'm worried by the changes made to the headers, and
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
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
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
info). The DB provides the central repository that we use for all
tools (including headers etc).

  So you have an internal infrastructure problem which is the reason
an external fork of the code base, i.e. a long term nightmare. The
answer is really 'fix your tools' the amount of damage due to the fork
can't really be justified by an internal database format problem.

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

  You had to patch the applications you compiled against the LSB
of libxml2? If yes, then you know it's a bad thing, you don't need to
IMHO. I have been in the standard business since 98 (XML @ W3C) and if
is a lesson I have learned is that 'oh, we will fix that in version 2'
doesn't work, precisely because for a standard to be useful, it must
cast in stone, if you need to wait for LSB4 to do it right, then
waiting. I have seen the mess it is to retrofit new changes in an
issued standard (xml:base and xml:id in XML-1.0), I would rather avoid
this for libxml2 too. Maybe it's too far streched to be relevant, but
does not sound good to me. On the other hand if the applications
as is without troubles, then okay, I will just keep my finger crossed


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]