Bug #35877 for XML-Compile: fractionDigits

Wed May 14 09:05:00 2008 drew [...] drewtaylor.com - Ticket created

Subject:

fractionDigits

(I'm not sure if this is a bug or not because I can't decipher what the Schema spec means.) I'm using a schema which defines the following element with a fractionalDigits facet: <xs:simpleType name="Money"> <xs:restriction base="xs:decimal"> <xs:fractionDigits value="3"/> </xs:restriction> </xs:simpleType> When using a WRITER, it turns '123.00' into '123.000'. A colleague believes that this should be interpreted as "up to x digits", while the current X::C implementation is saying "must have x digits". Which is correct? I can't figure out what the spec is trying to say! The bit of the spec is: "[Definition:] fractionDigits controls the size of the minimum difference between values in the ·value space· of datatypes ·derived· from decimal, by restricting the ·value space· to numbers that are expressible as i × 10^-n where i and n are integers and 0 <= n <= fractionDigits. The value of fractionDigits ·must· be a nonNegativeInteger. The term fractionDigits is chosen to reflect the fact that it restricts the ·value space· to those values that can be represented lexically using at most fractionDigits to the right of the decimal point. Note that it does not restrict the ·lexical space· directly; a non-·canonical lexical representation· that adds additional leading zero digits or trailing fractional zero digits is still permitted."

Wed May 14 09:45:05 2008 solutions [...] overmeer.net - Correspondence added

Subject:	Re: [rt.cpan.org #35877] fractionDigits
Date:	Wed, 14 May 2008 15:44:40 +0200
To:	Drew Taylor via RT <bug-XML-Compile [...] rt.cpan.org>
From:	Mark Overmeer <solutions [...] overmeer.net>

* Drew Taylor via RT (bug-XML-Compile@rt.cpan.org) [080514 13:05]: Show quoted text

> Wed May 14 09:05:00 2008: Request 35877 was acted upon. > Transaction: Ticket created by drew@drewtaylor.com > Queue: XML-Compile > Subject: fractionDigits > > (I'm not sure if this is a bug or not because I can't decipher what > the Schema spec means.)

If a native speaker does not understand them, then imagin how the rest of the world has to struggle. Show quoted text

> When using a WRITER, it turns '123.00' into '123.000'. A colleague > believes that this should be interpreted as "up to x digits", while > the current X::C implementation is saying "must have x digits". Which > is correct? I can't figure out what the spec is trying to say!

Actually, the implementation says: does get x digits. The problems with floating point numbers is always the rounding. 123.00 may be stored as 1.2199997. The problem with Perl is that I cannot see whether the value is kept as string or as value. As result, the only thing I could improve is to get rid of all trailing zeros. There is no "precission" indicator in Perl's floats. This is the code in XML/Compile/Schema/BuiltInFacets.pm sub _fractionDigits($$$) { my $nr = $_[2]; sub { sprintf "%.${nr}f", $_[0] }; } Gladly, 123.00 == 123.000 -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net

Wed May 14 09:45:14 2008 The RT System itself - Status changed from 'new' to 'open'

Wed May 14 10:19:36 2008 drew [...] drewtaylor.com - Correspondence added

Subject:	Re: [rt.cpan.org #35877] fractionDigits
Date:	Wed, 14 May 2008 15:15:20 +0100
To:	bug-XML-Compile [...] rt.cpan.org
From:	Drew Taylor <drew [...] drewtaylor.com>

On 14 May 2008, at 14:45, Mark Overmeer via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=35877 > > > * Drew Taylor via RT (bug-XML-Compile@rt.cpan.org) [080514 13:05]:

>> Wed May 14 09:05:00 2008: Request 35877 was acted upon. >> Transaction: Ticket created by drew@drewtaylor.com >> Queue: XML-Compile >> Subject: fractionDigits >> >> (I'm not sure if this is a bug or not because I can't decipher what >> the Schema spec means.)

> > If a native speaker does not understand them, then imagin how the rest > of the world has to struggle.

I can only imagine. :-) Specs are never easy to read, and XML Schema follows the trend. Googling leads me to believe that the intended application is "no longer than x fractional digits" rather than "make this x fractional digits long". Show quoted text

>> When using a WRITER, it turns '123.00' into '123.000'. A colleague >> believes that this should be interpreted as "up to x digits", while >> the current X::C implementation is saying "must have x digits". Which >> is correct? I can't figure out what the spec is trying to say!

> > Actually, the implementation says: does get x digits. The problems > with > floating point numbers is always the rounding. 123.00 may be stored > as 1.2199997. The problem with Perl is that I cannot see whether the > value is kept as string or as value.

I see your point, but in looking at the other built-in facets none of the others actually change the value. Rather they just check if the restriction is followed and return the original value. I think I'd be happier with something as stupidly simple as: sub _fractionDigits() { my (....) = @_; my ($whole, $fraction) = split /\./, $number; return $number if $length $fraction <= $max_length; error... } It's absolutely dumb, and assuredly will cause confusion at some point. BUT it also doesn't change my data either. I'll leave it at that until I come up with a better solution. Show quoted text

> As result, the only thing I could improve is to get rid of all > trailing > zeros. There is no "precission" indicator in Perl's floats. This is > the code in XML/Compile/Schema/BuiltInFacets.pm > > sub _fractionDigits($$$) > { my $nr = $_[2]; > sub { sprintf "%.${nr}f", $_[0] }; > } > > Gladly, 123.00 == 123.000

I realized I needed to switch to a numeric comparison (is($v1, $v2) vs cmp_ok($v1, '=', $v2), and then my tests are fine. Keep up the good work! One day I'll have sufficient understanding of the internals to actually send patches instead of just bug reports. Drew

Wed May 14 10:49:21 2008 solutions [...] overmeer.net - Correspondence added

Subject:	Re: [rt.cpan.org #35877] fractionDigits
Date:	Wed, 14 May 2008 16:48:49 +0200
To:	Drew Taylor via RT <bug-XML-Compile [...] rt.cpan.org>
From:	Mark Overmeer <solutions [...] overmeer.net>

* Drew Taylor via RT (bug-XML-Compile@rt.cpan.org) [080514 14:19]: Show quoted text

> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=35877 >

> > If a native speaker does not understand them, then imagin how the rest > > of the world has to struggle.

> > I can only imagine. :-) Specs are never easy to read, and XML Schema > follows the trend.

The RFCs are usually far more readible. These XML standards are made by librarians, not programmers... they seem to want to show-off their language "skills". Show quoted text

> > floating point numbers is always the rounding. 123.00 may be stored > > as 1.2199997. The problem with Perl is that I cannot see whether the > > value is kept as string or as value.

> > I see your point, but in looking at the other built-in facets none of > the others actually change the value. Rather they just check if the > restriction is followed and return the original value. I think I'd be > happier with something as stupidly simple as: > > sub _fractionDigits() { > my (....) = @_; > my ($whole, $fraction) = split /\./, $number; > return $number if $length $fraction <= $max_length; > error... > }

So, this would be wrong, because it will die on rounding errors, for instance for the number above. In the general case, I cannot decide for a lesser number of digits than the fractionDigits specify. Show quoted text

> I realized I needed to switch to a numeric comparison (is($v1, $v2) vs > cmp_ok($v1, '=', $v2), and then my tests are fine.

cmp_ok($v1, '==', $v2) Show quoted text

> Keep up the good work! One day I'll have sufficient understanding of > the internals to actually send patches instead of just bug reports.

I am already glad with concise bug-reports. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net

Fri May 23 03:50:07 2008 MARKOV [...] cpan.org - Correspondence added

The current behavior is best we can do, and standards compliant... only not minimal.

Fri May 23 03:50:09 2008 MARKOV [...] cpan.org - Status changed from 'open' to 'resolved'