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

[Daniel Veillard <veillard redhat com>]

On Thu, Oct 20, 2005 at 03:46:17PM -0700, Jain, Nilesh wrote:
> see. My concern started when I ran the older version of internal
> regression test against the newer version of library to ensure behavior
> stability, and there I see some variation. I was assuming that these
> test are only testing APIs visible to application, my assumption was
> wrong. So in this case my conclusion is that those test cases are also
> testing part of functionality which is not directly visible to
> application. Is my understanding correct.

  No. they are visible sometimes, but usually apps don't see them.
There are variations. They are potentially visible to applications
for example it's highly suggested to upgrade libxslt as the same time
as libxml2 as it abuses a lot of public informations exposed by libxml2.
But it's the application most tightly coupled to libxml2 internal 
representation that I know of, the second would probably be the PHP
and Perl bindings to libxml2 and libxslt, and those don't need
to get upgraded when libxml2 changes unless I made a mistake.
  You want a garantee that apps won't see changes ever, and there is
no way I can garantee that considering that in libxml2 nearly all 
internals structures are public, and the fact that the standards and
their understanding may be adjusted.

  If you can't live with this, then forget about libxml2 in LSB because

    1/ there is no way I will drop compatibility to standards due to
       a guarantee to applications, the data and their correct processing
       is way more long term and crucial than the pieces of code and tools
       which manipulates them. Data integrity primes over code, period.
    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 
       libxml2.

That said I think libxml2 is a very stable piece of code for most apps which
uses it for standard processing of XML, as the Red Hat maintainer for it 
for the last 5 years, I only had to deal with 1 serious issue about it for
RHEL maintainance, and that was a security issue not a compatibility problem.
As a maintainer when I know that I need to introduce a serious change in
behaviour, I usually create a new API instead of taking the risk of breaking
apps, but minor changes sometimes have to go though.
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 !)

  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.

  Thanks,

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/