Issue with Expansion handling of type maps and @none

[kasei]

Expansion algorithm step 13.8.3.7.5:

Otherwise, if container mapping includes @type initialize types to the concatenation of expanded index with any existing values of @type in item. If expanded index is @none, do not concatenate expanded index to types. Add the key-value pair (@type-types) to item.

Based on test tm012, I don't think this key-value pair is meant to be added to item in the case that expanded index is @none. If that is the case, this text can likely be simplified, as the "If expanded index is @none" condition will apply to the entire body of this step.

Also, the word choice of "concatenation" is confusing here. By context, I believe that what is being described is an array, types, that should possibly contain expanded index, and definitely contain any existing values of @type in item. Is there a way to improve this language to not risk confusion with string concatenation?

[gkellogg]

It probably should have used wording symmetric to the previous, where a check for expanded index being @none predicates the further steps.

The following should have the intended meaning:

Otherwise, if container mapping includes @type and expanded index is not @none, initialize types to the a new array consisting of expanded index followed by any existing valuers of @type in item. Add the key-value pair (@type-types) to item.

Note that we also use "concatenation" in 13.8.3.7.2 (for @index), but I believe that concatenation is a well defined concept on arrays, so rewording simply to replace this would be gratuitous.

[kasei]

@gkellogg I think concatenation is well-defined when both operands are arrays. But in this case, it's an array and a string, right? (Which in the JS case would be push, but might also be called append...)

[kasei]

Agree with your new proposed text; it is much clearer.

[gkellogg]

@kasei this is updated in PR #274. Please indicate if this satisfies your issue.

[kasei]

@gkellogg yes, looks good. Thanks.