Inconsistency between Syntax and API specs

[dlongley]

The JSON-LD Syntax spec indicates that the values of keys in a language map may be null. However, the Expansion Algorithm raises an error if a value is not a string (therefore not allowing null). See:

7.5.2.2.1) item must be a string, otherwise an invalid language map value error has been detected and processing is aborted.

Similarly, the invalid language map value error definition in the API spec doesn't mention allowing null.

@lanthaler, @gkellogg, @msporny -- thoughts on the proper resolution? Which spec do you think is incorrect?

I believe we have no tests for using null values in a language map -- and if I modify jsonld.js to allow null, no other tests fail.

Related to digitalbazaar/jsonld.js#76.

[gkellogg]

My implementation raises an error if the value of a language map isn't either a string, or an array of strings. But, in this case, I think the Syntax doc should take precedence, and this is clearly an omission in the API. So, +1 to updating the algorithm to allow null.

[gkellogg]

I will note, however, that such results seem fairly useless.

{
    "@context": {
        "label": {
            "@container": "@language",
            "@id": "vocab:label"
        },
        "vocab": "http://example.com/vocab/"
    },
    "@id": "http://example.com/queen",
    "label": {
        "de": [
            "foo",
            null
        ],
        "en": null
    }
}

now expands to:

[
  {
    "@id": "http://example.com/queen",
    "http://example.com/vocab/label": [
      {
        "@value": "foo",
        "@language": "de"
      },
      {
        "@value": null,
        "@language": "de"
      },
      {
        "@value": null,
        "@language": "en"
      }
    ]
  }
]

in my implementation

[lanthaler]

This is clearly an oversight. I think we should be consistent here and just drop such entries as we do everywhere else. As Gregg noted, processing them “naively” doesn’t make much sense.

[dlongley]

This seems to be a problem on Step 7.4.7 as well.

[dlongley]

I resolved the problem with Step 7.4.7 in jsonld.js by just dropping the @language property when expanding (if its value is null). This is the same effect, I believe, setting @language to null would have (no @language is the same as @language: null when in expanded form).

[nichtich]

This bug had not been fully fixed yet, try this test case:

{
  "@context": { "f:foo": { "@container": "@language" } },
  "f:foo": { "en": "foo", "fr": null }
}

The null value should be ignored instead of throwing an error.