ISSUE-129: JSON-LD xsd:integer lossless conversion

LC2 - Hawke - Native Type Conversion

JSON-LD xsd:integer lossless conversion

JSON-LD-API allows certain RDF literals to be mapped to JSON numbers (if
the "use native types" flag is set), but I don't think the mapping rules
are as good as they could be. Markus concurs, although I'm not sure we
quite agree on what they should be.

Now, that warning about lossless conversion can be rendered unnecessary,
I believe, by saying in situations where there might be a loss, one MUST
NOT convert to a number. It's true we don't know exactly when there
might be a loss, but after talking with Markus, I'm pretty confident
that using the range of 32-bit integers will work well. JavaScript
requires 64-bit IEEE, so it can handle intergers up to 53-bits, and
other systems like PHP (on 32-bit systems) use 32-bit ints for (integer)
numbers. I propose an additional test case showing:

"1"^^xs:int // not native since it's 'int' not 'integer'
"01"^^xs:integer // not native since it's not in canonical form

These rules will make xs:integer data round tripping through JSON-LD
perfectly lossless, I believe, on systems that can handle at least 32
bit integers.

I'm paying attention to this mostly because I'm building RDF data
synchronization stuff in JavaScript. I need the code to not corrupt
data (even seemingly harmless corruption will screw up synchronization),
and I'd like to align it with JSON-LD.

On a related topic, there's still the problem of xs:double. I don't
have a good solution there. I think the only way to prevent datatype
corruption there is to say don't use native number when the value
happens to be an integer. But that's pretty painful -- you don't want
different code paths just because the value happens to be an integer.
:-/ (Or have a custom JSON parson that notices the ".0".... but
that's kind of against the rules. Maybe we could suggest it for cases
that need type fidelity? I don't know.)