Open gkellogg opened 4 years ago
Would 1.1e1 be represented as 11? Presumably, as JSON just has a single numeric type.
Yes, that is also my understanding.
But, there are some JSON Canonicalization considerations that might apply (e.g., big integers)
The conversion to CBOR is defined for the JSON-LD internal representation, not the JSON text format. So we are dealing with ES6 numbers (IIUC), so there should be no such problem.
Where the
@value
is a string...
Gosh, I forgot, @value
could be a number of a bool... :-/
If we loose the value object, then we're not going to be able to round-trip.
The intent is not to lose the object, but to fallback to the general rule for objects (that should be made more explicit, I gues). So
{ "@value": null, "@type": "http://www.w3.org/2001/XMLSchema#double"}
would be encoded "as is" in CBOR, with a native CBOR boolean as the value of @value
.
Would
1.1e1
be represented as11
? Presumably, as JSON just has a single numeric type. But, there are some JSON Canonicalization considerations that might apply (e.g., big integers)Also, numbers without a fractional part, but with a negative exponent, or positive exponent greater than 20.
Where the
@value
is a string which has the canonical form of anxsd:integer
? If we loose the value object, then we're not going to be able to round-trip.What about date and type? A lot of JSON data likely represents dates or dateTime. Should this be supported in transformation? (base64Binary sort of opens the door).