Part of that issue is a jsonld.js issue, but test coverage doesn't exist for all this (yet), and it's unclear how to handle various situations. So I fell down the hole of exploring this.
But if @set creates an array of JSON literal values, then the parsing code would need to know this is a @set, otherwise it would be interpreted directly as a JSON literal array.
A related situation is if you try to compact multiple values to a @json term. If it uses an array, then a parser would see that literal array.
An oddity of jsonld.js is that if you compact JSON and non-JSON values to a @json term, it will use the compacted term for the JSON, and the expanded term for the non-JSON. I'm not sure if that is correct, or just a quirk of implementation and @json matching of some sort.
I wrote a variety of tests to cover many situations. As a first pass, I made the tests do what seemed like would "make sense", but they may not match specs. This in no way covers all the ways these features can be used or misused. This @json feature seems to add more complexity than expected.
Change compact/js07 compaction output for @json and @set of a JSON literal array. Add an array around whatever the literal was, in this case a literal array.
Propose new multiple JSON literals error code when trying to add multiple JSON literals as values for a property not declared a @set.
Use invalid set or array object when expanding a @json term declared a @set or @list and an array is not used.
Various combinations of these things.
The above is by no means exhaustive. Other constructs probably also need more explicit @json handling and tests. Help needed.
The above would at least allow JSON literals to be used as single values, as multiple values in explicit sets and lists, and for expansion and compaction, and I think all would work for round trips.
I think use of @json that causes these issues has been minimal so far. It would be good to add test coverage for expected behavior and update specs as needed to handle various use cases.
The 1.1 spec and test cases are missing coverage of how to handle various
@jsonprocessing issues and possible data.This work started when looking into a a jsonld.js issue about compacting a JSON literal array: https://github.com/digitalbazaar/jsonld.js/issues/509
Part of that issue is a jsonld.js issue, but test coverage doesn't exist for all this (yet), and it's unclear how to handle various situations. So I fell down the hole of exploring this.
Handling JSON literal arrays has some rough spots. The
compact/js07test would seem to indicate even if@setis used, a jSON literal is not put in an array, which is not what would expect based on: https://www.w3.org/TR/json-ld11/#representing-singular-values-as-arrays.But if
@setcreates an array of JSON literal values, then the parsing code would need to know this is a@set, otherwise it would be interpreted directly as a JSON literal array.A related situation is if you try to compact multiple values to a
@jsonterm. If it uses an array, then a parser would see that literal array.An oddity of jsonld.js is that if you compact JSON and non-JSON values to a
@jsonterm, it will use the compacted term for the JSON, and the expanded term for the non-JSON. I'm not sure if that is correct, or just a quirk of implementation and@jsonmatching of some sort.I wrote a variety of tests to cover many situations. As a first pass, I made the tests do what seemed like would "make sense", but they may not match specs. This in no way covers all the ways these features can be used or misused. This
@jsonfeature seems to add more complexity than expected.compact/js07compaction output for@jsonand@setof a JSON literal array. Add an array around whatever the literal was, in this case a literal array.multiple JSON literalserror code when trying to add multiple JSON literals as values for a property not declared a@set.invalid set or array objectwhen expanding a@jsonterm declared a@setor@listand an array is not used.The above is by no means exhaustive. Other constructs probably also need more explicit
@jsonhandling and tests. Help needed.The above would at least allow JSON literals to be used as single values, as multiple values in explicit sets and lists, and for expansion and compaction, and I think all would work for round trips.
I think use of
@jsonthat causes these issues has been minimal so far. It would be good to add test coverage for expected behavior and update specs as needed to handle various use cases.First pass at test cases: https://github.com/w3c/json-ld-api/pull/559