Questions/comments

[gkellogg]

Numbers without a fractional part (integer numbers) are serialized as CBOR integers (major types 0 and 1), choosing the shortest form.

Would 1.1e1 be represented as 11? 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.

If the object is a value object with a @type of xsd:integer (TODO full IRI), an if its @value is a valid decimal representation of an integer, then the object is serialized as a CBOR integer (major type 0 or 1) choosing the shortest form.

Where the @value is a string which has the canonical form of an xsd: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).

[pchampin]

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.