On Tue, Nov 15, 2005 at 10:59:17PM -0800, Hisashi T Fujinaka wrote: > On Mon, 14 Nov 2005, Daniel Veillard wrote: > > >>- 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. > > I'm not understanding this. Do you mean the previous release of the > specification is distributed widely enough that it should be > semi-stable?
I mean that our level of problems with the specification is not much worse than the one from Microsoft or others XML Schemas implementations. We have one missing piece of the standard (redefines) and various bugs and specs understanding problems like everybody else. > > 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. > > Thanks for the suggestions. I'm taking a look at the runtest.c code to > see if we can do the schema test without the diff. Unfortunately, I'm > kind of new to the library, so I'm making slow progress. > > Thanks for the help with the counting bug, too. it's in the exact same code in testOneSchemas (from memory), if ret != 0 then just verify that the error output is not null instead of comparing byte by byte the error output. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
