Plural names for arrays

[govynnus]

Hello,
would it make sense for attributes that are arrays to have plural key names?

For example the artist attribute of a track:
artist, string array: The recording artists.
would become
artists, string array: The recording artists.

The other affected attributes would be genre, albumartist and composer.
I think pluralising the names in these cases would help make it clearer that they can have multiple values.

[sampsyo]

Hi! This brings up a deceptively deep issue that I've struggled with in the past: which fields should be lists and which should be single strings?

As discussed in #7 and decided in #7 (comment), we decided some fields should be lists and others should be single strings. But I still think this is kind of a weird place to be because it seems like we're likely to guess wrong about whether someone will want to have multiple values for a given field. Will someone eventually want to have multiple comments values, for example? Hard to say! But as we discussed on the thread, proactively making everything a list also seems bad.

Here's one simpler option, to wade back into that complex discussion: let's turn all these things (artist, genre, albumartist) back into normal strings, not arrays, in the same way that beets, GrooveBasin (#7 (comment)) and Mopidy (#7 (comment)) all do it. This will keep servers and clients simple, and I think the vast majority of software will want to look for a single string for artists.

We can treat "multiple values" as an extension for the future. That is, we'll come up with a principled way to add list version of otherwise-single-value fields. For example, a server that supports multiple artists will be able to specify ["Foo", "Bar"] for artists but will still construct a single string like "Foo and Bar" for clients that only want to deal with a single string.

How does that sound?

[govynnus]

Yes I thought it might be a complicated issue :-)

Your idea of having multiple values as an extensions sounds good

[govynnus]

Oops, clicked the button accidently, will continue below:

I remember reading #7 now, and there's lots of different possibilities, but single valued fields is definitely simplest, and at not much/no expense if arbitrary fields can have multiple values in an extension.
Then the client can decide what it wants (if the server supports both).

On a side note (related to #7 (comment)) I am in favour of keeping the artist attribute as well as artist resources, to keep a good level functionality in implementations that don't support artists. And for those that do I should think both the attribute and the resource would use the same string as a name, but I may be wrong.

[sampsyo]

Agreed. I disagree with my past self, basically: the artist string is still meaningful even in the absence of linked "artist" objects.