Timothee updates

[gkellogg]

• Add note that unordered arrays may contain duplicate values after expansion. For Lists, sets, and multisets #473. Other parts of Lists, sets, and multisets #473 are deferred.
• Updated step 11 of the Create Term Definition algorithm to use any boolean value of @protected, not just true. Fixes Create Term Definition algorithm, possible imprecision step 11 #475.
• Improve wording of expansion 13.8.3.7.2.3. Fixes Expansion Algorithm confusing Step 13.8.3.7.2.3 not covered by the expansion tests #477.
• Update step 13.8.3.6 of the Expansion algorithm to pass true for the from map parameter to properly manage reverting active contexts. Fixes What is the purpose of from map in the Expansion Algorithm? #478.
• Update step 13.4.6.2 of the Expansion algorithm to pass null for active property, as included blocks do not define a relationship to a referencing node. Fixes Expansion Algorithm, possible imprecision step 13.4.6.2 #479.
• Mark expand/0122 non-normative, as it results in an invalid JSON-LD result. Note: toRdf/e122 does not include a triple for this, so it remains normative. For Is the possibility of having @id: null in an expanded document intended? #480.

---

Preview | Diff

[gkellogg]

@iherman note that this updates the implementation report which now considers expand/0122 to be non-normative, as the resulting file is not legal JSON-LD.

[iherman]

I would like to freeze the document now. The Director is reviewing the PR submission (with one issue pending), which means that the text must be frozen as soon as the submission is accepted.

(The Director also looks at the diff between the current /TR version and the last version of the official CR...)

[gkellogg]

@iherman So, does that mean you'd like to back out the change that affects the implementation report, or just be sure it's in prior to acceptance?

[gkellogg]

@iherman: we have agreement on everything, we can pull this PR pending your clarification to changing the implementation report to show the affected test as being non-normative. If you don't want this change, I can back out the commit.

[iherman]

@gkellogg I am less worried about the implementation report, as long as it does not change our exit criteria results:-). We did agree (and I told the Director) that we intend to add new implementations, for example, to the report. I am worried about the specifications themselves.

I intend to set up the errata page/script for all documents this week. We should begin to use that if needed...

[gkellogg]

@gkellogg I am less worried about the implementation report, as long as it does not change our exit criteria results:-). We did agree (and I told the Director) that we intend to add new implementations, for example, to the report. I am worried about the specifications themselves.

IIRC, we agreed to make these changes to the spec, are you saying we shouldn’t pull the PR now? I’m confused.

[iherman]

@gkellogg I am less worried about the implementation report, as long as it does not change our exit criteria results:-). We did agree (and I told the Director) that we intend to add new implementations, for example, to the report. I am worried about the specifications themselves.

IIRC, we agreed to make these changes to the spec, are you saying we shouldn’t pull the PR now? I’m confused.

We are talking one another... reset:-) What I mean is:

• merge this PR, meaning the report as well as the spec gets a minor update
• no more PR-s on the spec
• PR-s on the report are o.k. for the future, too.

I am afraid we are in a violent agreement...

[gkellogg]

Okay, thanks!