Change elements: change writer, penciller, inker, colorist, letterer, coverArtist, editor, translator, publisher and imprint maxOccurs to -1

[Kara-Zor-El]

Where does this comes from?

I have not discussed this elsewhere but I am a developer of a open source eReader (JellyBook) who is looking to add proper ComicInfo support to my app

What is the rationale for adding support for this element?

Some comics may be worked on by a team of people where there is a team of each group who may work on the same comic.

Is the element already handled by any application or tool?

Some books May do: <Writer>Person 1, Person 2</Writer> This makes it unclear as all of the previous said categories are singular rather than plural entries

[gotson]

This is not gonna happen, as it would be breaking previous implementations. We know it's not ideal, but keeping compatibility is best.

[Kara-Zor-El]

I’m sorry if this comes off as rude but isn’t the point of new schema version to create changes including some breaking ones? Additionally, I don’t how it would break it since the minimum is still the same and some people might just choose to put them all in one tag which wouldn’t break anything but if people made multiple, “breaking” implementations of this would choose are probably implemented to get the first one which wouldn’t be inaccurate and I don’t think would cause major changes to just fix this for them.

[gotson]

We decided not to make breaking changes, only backward compatible changes.

It's not just about the schema, but about every app writing and reading comicinfo.xml already in the wild.

That change would only create more confusion, because some apps would write comma separated values in a field, some would write multiple times the same field, and readers would need to implement both to be correct.

We publish accepted usage of fields on the website to guide people willing to implement comicinfo.xml.

[ajslater]

fwiw @Kara-Zor-El, there are some fledgling efforts to create a new comic metadata standard that is not so limited. Current discussions are centered around Readium, OPDS v2.0 and the DiViNa media extension.

ComicInfo.xml is probably not the long term future of comic metadata, but may adopt non-breaking changes to be useful in the short term.

[gotson]

Indeed, Readium Packaging Format might be the future we need.