Re: [xml] XSD patch and tests
- From: Daniel Veillard <veillard redhat com>
- To: Charles Bozeman <cbozeman hiwaay net>
- Cc: libxml-list <xml gnome org>
- Subject: Re: [xml] XSD patch and tests
- Date: Sat, 2 Aug 2003 13:06:42 -0400
On Sat, Aug 02, 2003 at 12:41:27PM -0400, Daniel Veillard wrote:
On Thu, Jul 31, 2003 at 10:20:35PM -0500, Charles Bozeman wrote:
decimal types as strings. I have also included tests (that belong in
test/schemas) for boolean, hexBinary, and decimal types.
for hexBinary I understand but for the decimal, what is the gain ?
It seems to me that now the information stored about the decimal is a
textual form and retrieving the value needs to reparse it again. What
is the purpose of the change to the decimal implementation ? A conformance
problem, a limitation in the approach (the REC asks for 18 digit of
precision and I had those).
I would like to apply your patch but on the other hand I don't understand
the reason for most of the changes made, and a bit annoyed about not being
able to get the value for the decimal types, could you provide a bit
more informations ?
I used James Clark regression test before and after applying your patch,
I see serious conformance degradation, and memory leaks appearing in the
in the integer related types (diff appended). You can run the XSD regression
tests using the Python script:
./check-xsddata-test-suite.py
it uses the Relax-NG engine but tests the XSD Datatype implementation
conformance . The tests are in test/xsdtest/ which should be both in
CVS and on the distribution.
I glanced at the code too and it seems to be some problems like:
- XML_SCHEMA_FACET_TOTALDIGITS: uses the xmlSchemaValDecimal2ULong
function to get the number of digits
- That function uses sscanf((const char *)decimal->istr, "%lu", &base)
- I don't think the scanf function can process 18digits strings as
required by the spec (at least not in a portable fashion)
see section 3.2.3 decimal note:
"All ·minimally conforming· processors ·must· support decimal
numbers with a minimum of 18 decimal digits"
As pointed in the comment in my implementation this would require using
a long long type which is not portable, that's the reason of the
implementation based on 3 unsigned longs.
So I think more discussion will be needed before changing the decimal
implementation. In the meantime, could you separate the hexBinary patches
so that part can be fixed ?
thanks,
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]