Inconsistent management of empty terms

[pchampin]

According to Section 9. JSON-LD Grammar of the syntax document:

the term MUST NOT be an empty string ("") as not all programming languages are able to handle empty JSON keys

However:

• there is no step in the Context Processing algorithms for detecting empty term definitions,
• there is no test for it in the test-suite,
• implementations are handling this very heterogeneously (see below).

Consider the following example:

{
"@context": {
  "": "http://example.org/"
},
  "": "foo",
  ":bar": "baz"
}

• pyld and jsonld.js reject it with an error
• rdflib-jsonld accepts it and hallily expands both properties
• the Ruby distiller accepts it, expands "", but ignores ":bar".

For the record, this "blind spot" of the test-suite and algotithms dates back to JSON-LD 1.0.

What made me realize that (and makes me think this is a problem we should probably address) is that two contexts in prefixcommons' registry (mentionned by @hsolbrig in w3c/json-ld-syntax#329) have a term definition for the empty string, which makes them unusable with pyld or jsonld.js. Apparently, this went unnoticed because they are mostly using rdflib-jsonld...

I know it is late (too late?) to fix it, but I think the spec should be more explicit about how to handle a term definition when the term is the empty string (""). Rejecting it seems consistent with the grammar. And a test should therefore be added.

[hsolbrig]

the prefixcommons' registry ...have a term definition for the empty string, which makes them unusable with pyld or jsonld.js. ... Apparently, this went unnoticed because they are mostly using rdflib-jsonld...

Interestingly, I think that it went unnoticed because they were parsing the document as plain old JSON -- something that we may want to keep in mind when adding features that require the expanded form.

[iherman]

Interestingly, I think that it went unnoticed because they were parsing the document as plain old JSON -- something that we may want to keep in mind when adding features that require the expanded form.

Wow, of course! There are a number of cases when JSON-LD files are processed directly using JSON parsers (I do it with some other projects I am involved with, too). This may be a warning to be put somewhere (Best practices, maybe?).

[gkellogg]

I think we didn't create a test case for this, and no specific spec text, to not be too heavy handed, as it's really an interoperability issue. There is MUST language, so it shouldn't be necessary to have explicit algorithmic text for this to motivate a test case, if we chose to do so. But adding either or both a test case and spec text should be okay as a post-CR editorial change.

I think I suggested removing the restriction at one time, as I believe the PHP issues were solved, but the group chose not to re-address this, IIRC.

[pchampin]

@hsolbrig what I really meant was "it went unnoticed because WHEN they are using a JSON-LD processor, it seems to be rdflib-jsonld". I got it that the plain JSON use-case is dominant. But in that space, there's nothing we can do to avoid inconsistent behaviours...

@gkellogg

There is MUST language, so it shouldn't be necessary to have explicit algorithmic text for this

It seems to me that we do have algorithmic text for a number of things which are otherwise covered in the grammar, like raising invalid-base-direction, invalid-propagate-value.

I also understand your position; some normative text is here, so we shouldn't need more. On the other hand, the heterogeneity in implementations makes me think that we need to be more directive...

I can make a PR to address this.

[gkellogg]

I suggest we wait until after CR to make any such changes.

[davidlehn]

Did they have real use cases for the empty terms? Or is it just an oversight not caught by tools? I see that it's at least in the monarch_context.jsonld file, but I'm not sure where to look for how it's being used.

I think we should have tests for this to ensure data works similarly between implementations in order to ensure interoperability.

Or if there are real use cases, I'm in still in favor of relaxing empty term restriction to enable fun projects like term compaction and obfuscated JSON-LD. ;-)

[hsolbrig]

It is an oversight not caught by the tools. They do not use the empty namespace and are will remove them once the tools start complaining.

[pchampin]

Created a branch for this, but waiting till CR to make it into a PR.
https://github.com/w3c/json-ld-api/compare/reject_empty_term

[gkellogg]

@pchampin I think the way to do this is to mark it WIP: and use the draft PR capability. But, you can proceed with this now.