Hrefna (DHC) @hrefna@hachyderm.io
Public

RE: mamot.fr/@rigo/116122496081934

Actually, let's talk for a moment about this pernicious falsehood that you can "just interpret it as JSON."

1. The specs are different. A simple example of this is the matter of whether lists are sorted. This comes directly from the test suite: "JSON objects are compared member by member without regard to the ordering of members within the object." In standard JSON, [1,2,3] is an ordered list, that is only true in JSON-LD if the list is marked that way.

2. Variance in parser behavior. A JSON-LD parser is supposed to drop things that are not defined in the @'context, but JSON has no such limit. This means that with a slight difference in the @'context a field may be dropped by some parsers and included by others, _even if the field is theoretically supported by the underlying software_.

3. JSON-LD does not have a great way of representing arbitrary precision numbers. xsd:integer and xsd:double are the kinds of things you have.

Unless you define one, of course, but that brings us to

4. The context can rewrite the specification. Does "foo:bar" have meaning? In a well-formed JSON object backed by JSON Schema or Open API I can give you the answer that immediately. In a JSON object serialized from a protobuf following those standards I can give you a direct, clear, unequivocal meaning in the vast majority of cases.

The only times I can do that with JSON-LD are IF I HAVE PARSED THE CONTEXT, WHICH POSTS LIKE THIS TELL ME I DON'T NEED TO DO.

This again brings us back to variant parser behavior. If _your_ parser reads it as JSON-LD and _mine_ does not, we are NOT READING THE SAME OBJECTS in a way that can be controlled and manipulated maliciously.

5. Absolutely inane use of sum types that aren't even required to be LABELED sum types means that you may get a different payload structure entirely and have no way of interpreting it UNLESS you are using JSON-LD.

If an object can be a URI OR an object OR a value OR a list of URIs etc then validation requires checking ALL of these.

1/

mcc @mcc@mastodon.social
Public

@hrefnaHrefna (DHC) What I keep wondering is, would it be possible to define a subset of JSON-LD which has less flexibility— for example, perhaps more things are defined by convention, or the things the context may define are more limited in some way which lowers the processing time— but which is still prefixed with enough information that a compliant JSON-LD parser derives the same object?

0
0
0

If you have a fediverse account, you can quote this note from your own instance. Search https://mastodon.social/users/mcc/statuses/116126187206698167 on your instance and quote it. (Note that quoting is not supported in Mastodon.)