The current proposal raises some questions about round-tripping, as pointed out in #7.
Currently, both 42 (in JSON) and
{ "@value": "42", "@type": "http://www.w3.org/2001/XMLSchema#integer"} are encoded identically in CBOR, using a native integer representation (major type 0). Parsing it back to JSON, we transform that native integer into a JSON number 42.
Semantically, both forms are equivalent for JSON-LD. But this means that CBOR would not preserve the expanded-ness of a JSON-LD document in the expanded form.
Is that a problem? I would tend to answer "no". Anyway, it will be further (in §4) suggested to first compact the JSON-LD document into a CBOR-friendly context, to get an even smaller representation.
The current proposal raises some questions about round-tripping, as pointed out in #7.
Currently, both
42(in JSON) and{ "@value": "42", "@type": "http://www.w3.org/2001/XMLSchema#integer"}are encoded identically in CBOR, using a native integer representation (major type 0). Parsing it back to JSON, we transform that native integer into a JSON number42.Semantically, both forms are equivalent for JSON-LD. But this means that CBOR would not preserve the expanded-ness of a JSON-LD document in the expanded form.
Is that a problem? I would tend to answer "no". Anyway, it will be further (in §4) suggested to first compact the JSON-LD document into a CBOR-friendly context, to get an even smaller representation.