JSON-LD 1.1 issue with double-`@graph` expansion

json-ld-issue-graph-simplification.md

In Expansion step 20, expanded result maps that contain only a @graph entry are simplified:

If result is a map that contains only an @graph entry, set result that value.

In test t0081, I believe the expansion of the "input" key:

  "input": {
    "@graph": {
      "value": "x"
    }
  }

will be simplified by step 20.

Before step 20:

{
	"@graph": [
		{
			"http://example.org/value": [
				{
					"@value": "x"
				}
			]
		}
	]
}

After step 20:

[
	{
		"http://example.org/value": [
			{
				"@value": "x"
			}
		]
	}
]

However, the expected test output seems to assume that this simplification does not happen, and contains a double-nesting of @graph entries.

This also goes back to changes in w3c/json-ld-api#295. I think the change to always return an array came about because there is text at the end of the 1.0 algorithm, which is missing:

If, after the above algorithm is run, the result is a JSON object that contains only an @graph key, set the result to the value of @graph's value. Otherwise, if the result is null, set it to an empty array. Finally, if the result is not an array, then set the result to an array containing only the result.

This paragraph, which is run after the algorithm, so is not part of the recursive algorithm, got rolled into steps 20-22. We should probably revert the change from #295 which moved these up, and go back to the 1.0 description, so that when the expansion algorithm is passed an object, it typically returns an object, and not an array. We can re-examine some of the other changes that came as a consequence of this.

I'll repeat this in w3c/json-ld-api#294.

(cross-posting with #294)

FWIW, I would strongly prefer not reverting to the 1.0 language without updates to the language used at most of the places where the expansion algorithm is called. Ideally I think this would be better resolved by breaking up Expansion into multiple sub-algorithms:

• the main body of the current expansion algorithm
• steps 13 and 14 which currently require the use of the "recursively repeat" language (which differs from all other uses of "recursive" invocation in the spec)
• the 1.0-era post-processing text, but described using algorithmic steps, not prose

I understand CR makes this sort of change difficult, but I think it would result in a much simpler description of the expansion algorithm.

Understood, but it’s a big change coming late.

I think we can move the end steps to the API description, which has its own steps. All API methods that depend on expansion use the API expand() method entrypoint.