Handling `@context` in Create Term Definition

[multimeric]

In the latest and draft versions of the JSON-LD 1.1 Processing Algorithms and API spec, section 21 reads as follows:

21. If value contains the entry @context:
    21.1 If processing mode is json-ld-1.0, an invalid term definition has been detected and processing is aborted.
    21.2 Initialize context to the value associated with the @context entry, which is treated as a local context.
    21.3 Invoke the Context Processing algorithm using the active context, context as local context, base URL, true for override protected, a copy of remote contexts, and false for validate scoped context. If any error is detected, an invalid scoped context error has been detected and processing is aborted.
    Note
    The result of the Context Processing algorithm is discarded; it is called to detect errors at definition time. If used, the context will be re-processed and applied to the active context as part of expansion or compaction.
    21.4 Set the local context of definition to context, and base URL to base URL.

This doesn't make sense to me for a few reasons:

1. A term definition doesn't have a property called "local context", it just has a property called "context", as defined in section 4.1 Context Processing Algorithm
2. The context variable which we pull from the @context variable is, at this stage, just a map. It doesn't become a context object until we execute the context processing algorithm on it. However, we throw away the result of this algorithm and instead just set the term definition's context to context, which is the "raw" unprocessed version. The same section as above specifies that the type of context for a Term Definition is context, which to me means a processed context, the result of the context processing algorithm.

Therefore I think the fix is to remove the "note" from this section, and instead assign term_definition.context = create_term_definition(context, ...). Happy to put in a PR, I just can't find the part of the repo where the latest spec is actually built from.

[multimeric]

Closing because I think this was the wrong repo to file this issue. Moved to w3c/json-ld-api#621.