Re: [xml] XML regression test cases...

On Fri, Oct 21, 2005 at 10:59:03AM -0700, Jain, Nilesh wrote:
    2/ an LSB version blocking on one given revision of libxml2 API/ABI
       would be the exact same mistake as was done for the RPM integration
       in LSB, and with a couple years evaluation since that was done, this
       approach is a complete failure, I prefer to not repeat that with 

That's why we are having deep discussion, not to repeat the mistake. 

  good :-)

You want a totally white statement, I can only garantee a clear shade of grey
and I affirm that pure white is both unrealistic and way too costly to the
point of being near useless, potentially dangerous (bugs must be fixed to not
end up with broken data !)

I understand this and not looking for 100% white statement. There is
always a gray area, but it is important to understand how big and deep
it is.


  Now the decision is on your side, I can't really discuss more at that meta
level, the thread has been going on deeply enough that I'm out of argument. If
you want to examine precise potential changes, then look at the diff of the
regressions and ask for them precisely (after haviong looked at them), and
then I will explain why it didn't matter or the decision was made, but only
on a precise case by case basis.

I think it is very important to understand we should draw the line. The

  basically any code which modifies the tree without going though the 
API function is potentially at risk one day or another, I try hard to not
break them though, and I don't see any need to change this, i.e. if the
code works with 2.6.22 then it should work in the foreseeable future.
  But the line can't be drawn easilly because people have to access the
node directly, for example when navigating within the tree (there is no
accessor function for navigation, i.e. most users of the tree need to see
the structures).  

best approach to include XML into LSB specification is that, we can
limit the internal structure and interfaces, and only allow the one
which application is supposed to use or using because other low level
users [libxslt, etc] are already potential candidate for inclusion in
LSB. This way we can achieve the stability of specification as good as
stability of libxml2 for application. 

  There isn't really a way to split. For example any program using the
DOM need to include <libxml/tree.h> and dereference node->type to process
node based on their type. Hiding the structures would be a awful lot of work,
speed and versatility when processing with libxml2 also comes from the openess 
of the library. First I don't really have time for such a work, and second I
think it would not be useful for most of my userbase, i.e. low priority.

Now I would need your help to identify the what should be included or
what should not be, work with you on case by case basis.

  I already pointed at the header files which I think must be included.
Trying to split them to subpart sounds a lot like an LSB specific release that
noone would use i.e. repeating the rpm fiasco. I guess you don't really like
the answer but I think limiting to the set of header we discussed is already
a first step which I think would be sufficient, going down to "this function but
not that one" kind sounds a lot of work, and there isn't any function that I
explicitely want to break in the future. That wouldn't avoid anything to
the change in the regression tests you saw too, such processing changes will
not be avoided in selecting out parts of the API or even structures, some would
be seen as well if doing just 

   doc = xmlReadFile("....", NULL, 0);
   xmlSaveFile("-", doc);

i.e. the two most core and basic calls of the library.


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]