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

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

  okay I missed that.

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

  So you have an internal infrastructure problem which is the reason for
an external fork of the code base, i.e. a long term nightmare. The obvious
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 LSB4.0
timeframe, we will need to find a different solution and avoid these LSB
specific headers.

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