We should allow for quite a large number of digits for packed decimal numbers. Enough to allow for the full numeric range of the type in the case of xs:unsignedLong for example it's quite a bit more than 64 bits.
For xs:nonNegativeInteger and xs:decimal and xs:integer, I think we should allow at least 64 digits so 256 + 8 bits to allow for the sign. The minimum is a single digit of course. I'm not sure there is a compelling reason to have an upper limit however. On Thu, Dec 19, 2024 at 5:02 PM Adams, Joshua <jad...@owlcyberdefense.com> wrote: > > While working on https://github.com/apache/daffodil/pull/1391 I was > attempting to create a range check test for packed decimal and I noticed that > attempting to represent INT_MAX (2,147,483,647) would require at least 5 > bytes (6 with sign byte). However, having a schema element with > type="xs:int" length="5" will result in an Schema Definition Error saying > that the length in bits for an xs:int must be between 1 and 32. So it seems > that we are using the same range checks for packed numbers as we are for 2's > complement. > > According to section 12.3.7.2.3 of the spec: > > "The maximum specified length of a packed decimal number is > implementation-defined." > > I'm not sure if the maximum specified length is referring to the max length > for each numeric type, but assuming it is do we want to use the same checks > as we do for 2's complement? I believe the changes I have made in #1391 will > create appropriate errors when attempting to convert a number into a smaller > type, but I can't currently test this as packed numbers will require more > bytes than 2's complement and trigger the SDE. Should these range checks be > changed to check the value represented by the packed number instead of the > number of bytes it takes up? Or will having an xs:int with length > 4 end up > being confusing? > > Thoughts? > > Josh
