New element: Tags

[gotson]

Where does this comes from?

The request came up via Komga.

What is the rationale for adding support for this element?

Tags are ubiquitous nowadays in pretty much every metadata management solution. Komga already handle tags, and many metadata sources also handle tags.

Is the element already handled by any application or tool?

NHentai already writes a Tags element, probably containing a comma-separated list of tags. See here.

[gotson]

Given we are creating something new, we have a couple options for the implementation:

1. Use a repeatable Tag element: <xs:element minOccurs="0" default="" name="Tag" type="xs:string" />

2. Use a single Tags element, comma separated, to be split by the consumer: <xs:element minOccurs="0" maxOccurs="1" default="" name="Tags" type="xs:string" />

Since NHentai already has an implementation, Option 1 would imply some changes on their end.

---

I have a personal preference for Option 1, which is more explicit, and removes the interpretation on consumer side. However Option 2 is more in line with the existing elements in v2.0.

[gotson]

@RicterZ FYI

[majora2007]

I really like this proposal. Tags is def something that is needed from the Manga side as well, to provide more finite information that does not match well in a Genre. Personally, Option 1 is my favorite as well. It is very clear from a consumption standpoint and allows consumers to provide case insensitive matching.

[gotson]

allows consumers to provide case insensitive matching

Both options should allow this

[gotson]

Option 1 is my favorite as well. It is very clear from a consumption standpoint

I see 2 problems with Option 1, even though it's my favorite:

• an existing tool already created files with Option 2. Not sure how much is already out there, but that's definitely something.
• it would be different from the other existing fields. For instance Genre, but also all the author roles, can already contain multiple values, and those are comma separated. Consistency with the existing fields probably trumps the better field definition in that case.

Going for Option 2 has one clear disadvantage, which is that individual values cannot contain the , character, but that's not a very common character in tags I would say.

[majora2007]

Yes this is the problem that we face. Do we stick to how the existing tags are setup or move the standard forward to be a bit more flexible. I agree, using "," isn't an issue here. Which tool already supports it?

[gotson]

Which tool already supports it?

NHentai, which is how the request came to Komga.

NHentai already writes a Tags element, probably containing a comma-separated list of tags. See here.

[gotson]

2. Use a single Tags element, comma separated, to be split by the consumer: <xs:element minOccurs="0" maxOccurs="1" default="" name="Tags" type="xs:string" />

I'll cast my vote for option 2, to keep the semantic closer to what already exists 👍🏻

[majora2007]

2. Use a single Tags element, comma separated, to be split by the consumer: <xs:element minOccurs="0" maxOccurs="1" default="" name="Tags" type="xs:string" />

I'll cast my vote for option 2, to keep the semantic closer to what already exists 👍🏻

I'm in the same thinking as you.

If we add these new fields, is it worth putting a Version field which will dictate the standard of comicInfo which coincides with this living standard we are building?

[gotson]

If we add these new fields, is it worth putting a Version field which will dictate the standard of comicInfo which coincides with this living standard we are building?

Those changes are non-breaking, we only add new fields.

v1 and v2 of the schemas are not compatible, because there's a breaking change on the Manga element.

Those new fields will be available in a v2.1 draft of the schema. As long as consumers don't fail if the fields are not present, it should be fine. This is actually the default behaviour, since fields that are not filled are not present in the ComicInfo.xml as of now, so consumers already behave that way.

[majora2007]

I'm good to merge this into the v2.1 draft when you are. As of v0.5, Kavita supports this tag out of the box.

[gotson]

I'm good to merge this into the v2.1 draft when you are. As of v0.5, Kavita supports this tag out of the box.

I'll take care of updating the schema and the documentation later today 👍🏻