Exception while unmarshalling Integer with an element bigger than 32-bit

[Cantor, Scott]

On 6/6/12 4:26 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Otherwise it's used in few places in the XML signature and encryption
>schemas.  Interestingly one of them is X509SerialNumber and I have a
>note that the Java X509Certificate interface actually exposes that via
>BigInteger and so to be consistent we wound up special casing our
>X509SerialNumber interface to use BigInteger also, rather than
>inheriting from XSInteger.

Yes. I tried to get them to fix that in 1.1, and instead they decided to
go with a new X509Digest element to replace the functionality of the old
element. In terms of our usage, it should be a string since that's what it
was meant to be.

>But I think the OP's problem IIUC was processing an Assertion with an
>AttributeValue with an xsi:type of xsd:integer.  That seems a legitimate
>use case and we can't really know or impose any meaningful restrictions
>there.

It's only legitimate if the intent is to perform math on the value. If
not, it should be a string, and failure to do that runs into the same
breakage issues that affected X509SerialNumber.

>Hmm, I guess I didn't really think of it that way.  Obviously supporting
>an "infinite" size is literally impossible, but I would assume that the
>existence of xsd:integer implies or assumes common support for values
>larger than say a long/64-bits?

The text reads:

All ·minimally conforming· processors must support decimal values whose
absolute value can be expressed as i / 10k, where i and k are nonnegative
integers such that i < 1016 and
k ¾ 16 (i.e., those expressible with sixteen total digits).


libxml2's validator in fact chokes on anything above that. You don't want
to send around data that relies on the consumer NOT validating it. It's
just asking for trouble. Using xsi:type implies that you are signaling
something to a validator. So those constraints do come into play.

-- Scott