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

["Jain, Nilesh" <nilesh jain intel com>]

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

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.

Thanks,
Nilesh