You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: