GNOME.org
 

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

Thanks for your help and feedback.

-Rajesh


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

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


  okay I missed that.


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


  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

--
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/
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]