Gregg Kellogg
Gregg Kellogg
@iherman Should this be marked as Editorial, given our general policy about tests winning out over algorithm text?
Summary: Update the [Context Processing Algorithm](https://www.w3.org/TR/json-ld11-api/#algorithm) steps 5.1.1 and 5.1.2 to look for protected term definitions in _result_ not _active context_ and to initialize _result_ to an initial active context...
Not really inconsistent with the text, though. It just says if it's not an IRI that an error is detected, and doesn't call to validate the IRI. That said, it...
> The value of keys that are not keywords **MUST** be either an IRI, a compact IRI, a term, a blank node identifier, a keyword, null, or an expanded term...
It seems that step 5 should look up the property-scoped context using _type-scoped context_ and not _active context_, although it does update the _active context_. Perhaps other implementors can comment,...
We have a backlog of updates to do to the spec, but the WG hasn't been active. It's captured as a raised erratum, which will eventually allow us to go...
Summary: Update step 6 of the [Compaction Algorithm](https://www.w3.org/TR/json-ld11-api/#algorithm-6) to check the _type-scoped context_ instead of the _active context_. > 6) If the [term definition](https://www.w3.org/TR/json-ld11/#dfn-term-definition) for _active property_ in _type-scoped context_...
This could be addressed by merging steps 13.4.3.1 and 13.4.3.2 in the Expansion algorithm, to check that the result of IRI expanding the value is a string, which it shouldn't...
@timothee-haudebourg This is addressed in #481 by marking expand/0122 non-normative. The issue remains deferred for the future.
I agree that the expansion algorithm shouldn't generate `{"@id": null}`, and we'll address this at a later point. My own implementation, which doesn't follow the spec, also generates a different...