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/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
