Original text:
3.3. <del> Parameterized Lists are arrays of parameterized identifiers, with one or more members. </del>  <del> A parameterized identifier is a primary identifier (a token}) with associated parameters, an ordered map of key-value pairs where the keys are short, textual strings and the values are items (item). There can be zero or more parameters, and keys are required to be unique. </del>  The ABNF for parameterized lists in HTTP/1 headers is: <del> In HTTP/1, each param-id is separated by a comma and optional </del>  whitespace (as in Lists), and the parameters are separated by semicolons.  For example:

Reviewer comments:
in , NAME asks about having Parameterised Lists whose parameterised identifiers are things other than Tokens. Because of the way SH is put together, I think this would be a fairly easy change, in terms of the spec and implementations; it would require a few more tests. The only downside I can think of immediately is that specs would need to constrain the type of the parameterised identifier themselves, and specify error handling (if it weren't the default "blow up"). Thoughts? I also wonder if we should come up with a better name than "parameterised identifier", especially since we've ditched "identifier" elsewhere. member name? member id? primary identifier?
That works, since splitting lists from parameterised lists. Are you thinking , or just adding a few types? It also changes my thinking a tiny bit on , although not much. I like "parameterised element" but that introduces a new word. "parameterised item" is a nice shade, if any item is allowed there, but "primary identifier" works too. :art: :paintbrush:
The downside here is that it would be very hard to represent in JSON -- e.g., in the . At least some programming languages support hashes/dictionaries/objects with arbitrary key types (e.g., Python, JavaScript, Ruby), but I'm not sure how widespread that is -- especially if folks represent the different between and with an object for . NAME is this a nice-to-have or something that's a blocker?
(Fwiw I do think we should call this a Parameterised Token)
At this point do we just have to accept that the SH data model is essentially a subset of the JavaScript model? Numbers are bounded by JavaScript's limitations, object keys have to be stringy, nobody likes 'token' because it isn't a native JS type... I don't mind if that's the case, but it would be good to just say it outright somewhere. It would also give us a solid position to start from when considering other proposals. Hmm, C++ and Go could be have issues mixing key types within a single map, and Perl is definitely not going to like non-string keys.
It doesn't have to be -- it's just easier for me to write tests this way :)
This was a nice-to-have for me. I’d worked around it by putting an unused string as the identifier. It looks like that workaround is no longer necessary?

Revised text:
3.3.  <ins> Parameterized Lists are arrays of parameterized items, with one or more members. </ins>  <ins> A parameterized item is an item (item) with associated parameters, an ordered map of key-value pairs where the keys are short, textual strings and the values are items (item).  There can be zero or more parameters, and keys are required to be unique. </ins> The ABNF for parameterized lists in HTTP/1 headers is:  <ins> In HTTP/1, each param-item is separated by a comma and optional </ins> whitespace (as in Lists), and the parameters are separated by semicolons.  For example: