Re: [xml] Proposal for libXML2 inclusion in LSB

[Daniel Veillard <veillard redhat com>]

On Sun, Nov 13, 2005 at 09:27:48PM -0800, Banginwar, Rajesh wrote:
> Hello,
>       After going through much discussion (thanks for Daniel's help
> and patience) and test analysis here are some of the findings and
> proposals:
>
> Please refer to the wiki page http://www.linuxbase.org/LSBWiki/LibXml2
> where we have done some analysis in addition to showing the findings in
> details.
>
> Also, please note that once the XML2 library is included LSB, the tests
> that we make part of runtime test suite now, will remain so for at least
> few months. So, if libxml2 comes with 2.4.23 or later versions, and
> distros pick them up and come for LSB certification, they will be using
> the current test suite (unless we get to change it before that). So
> please consider the following in this context.
>
> - There are many HTML regression test case failures when we ran old
> tests against new versions of the library. Most of the failures are due
> to minor white space and such formatting changes in the XML2 internal
> implementation. We propose to take out all HTML regression tests from
> the LSB runtime test suite. These include: 
> ## HTML regression tests
> ## Push HTML regression tests
> ## HTML SAX regression tests
> ## Push HTML SAX regression tests

  Removing the regression tests for HTML is okay, some adjustment may be
needed to ajust more closely to the way web browsers parse HTML (which is
way different from whatever you may read in the specs) so some flexibility
there will be needed.

> - We also propose that in addition to already identified modules like
> SAX1, nanoftp, nanohttp etc (please refer earlier emails from Daniel
> here), all schema related modules be not included in LSB desktop. It
> appears that this module is going through some active development. Even
> if the API remains stable, internal implementation changes --may--
> produce further failures if the current test suite is run against future
> versions. Of course, we may not have understood this completely, and
> will like to get feedback on this. What kind of changes, if any, is
> expected in schema modules?

   Inplesmantation of redefines except that no more than the amount of
change that Microsoft is about to do to its published and released MSXML4
XML toolkit deployed everywhere.
  XSD is instable because its specification is highly ambiguous sometimes even
contradictory at times. A number of changes are also about the way errors
are reported to provide *better* error messages, and deciding it is not
useful to user apps because the error messages improved in case the instance
does not validate sounds fairly wrong to me.
   Removing the API is the wrong thing to do, it just suggest the validation
should not be used, while it is good enough in most case. the regression tests
cover edge cases, precisely where problems were found, that's why it breaks
with older release and will break in the future.
   The right approach would be to design your own set of XSD test case,
covering XSD as it is used and not the edge case, and oh surprise you won't
see change to the "is this a valiud instance", and make your check based only
on the "is this a valid instance YES/NO" and do not run a diff on the error
message as this may vary if we improve them.

   Yes that's a part you won't get precooked/precoded from us, it will force
you to develop a bit of tests and modify the existing code a bit (like removing
a few lines), and you will magically find that the Schemas implementation looks
stable based on this.

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/