Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Mylar Age Ratings values to ComicInfo schema #25

Open
Majawat opened this issue May 18, 2022 · 1 comment
Open

Add Mylar Age Ratings values to ComicInfo schema #25

Majawat opened this issue May 18, 2022 · 1 comment
Labels
enhancement New feature or request RFC Request for comments

Comments

@Majawat
Copy link

Majawat commented May 18, 2022

I propose adding the content rating values that Mylar uses to the AgeRating field of ComicInfo.

These values are:

  • All Ages
  • 9+
  • 12+
  • 15+
  • 17+
  • Adult

These values closely (but not identical) resemble the DC/Marvel ratings system as described here: https://www.howtolovecomics.com/2020/02/10/comic-book-age-ratings, and I feel are good inclusions to the standard as they are clear and concise.

The current schema has lots of overlap and feels non-uniform in its values. This proposal does not suggest to remove the existing values, but to add existing values already used in a popular library management tool.

If the ComicInfo schema is meant to be a descriptive standard, then the inclusion of existing metadata would make sense. However, if the schema is meant to be prescriptive, then I would assume that the AgeRatings field would be pared down to a select few values and remove current ambiguity.

@gotson
Copy link
Member

gotson commented May 18, 2022

We won't be removing any values, as this project aims at keeping the schema backward compatible.

Adding values to the enum wouldn't hurt IMHO:

  • I doubt any consumer actually validate XML against the XSD. If that was the case, a 2.1 XML with the new values wouldn't validate against the 2.0 XSD.
  • The recommended approach for consumers (we still need to document that by the way!) is to be flexible around the schema. If a field is not there, ignore it. If you can't parse it for any reason, ignore it. The same would go for the new enum values, if you don't know about them, ignore it. Note that the schema itself in its original form is very rigid, for example forcing the order of the elements with a sequence, but in reality no consumer would enforce that.

@gotson gotson added enhancement New feature or request RFC Request for comments labels May 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request RFC Request for comments
Projects
None yet
Development

No branches or pull requests

2 participants