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

On Fri, 2005-10-21 at 06:40 -0400, Daniel Veillard wrote:
  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.

When I am talking about application, I wasn't really considering libxslt
as apps, though they are users. libxslt other run time env (Perl, PHP,
etc) are already in consideration list of LSB. 

  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.

Neither I want that.

    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. 

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.

That's really a good that apps are really not impacted by these changes.

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]