[ajslater]

I have no idea if this fits with any of your ideas about MetronInfo. Just a suggestion.

Adds three optional elements to <Series> so a series' end year, publication status and description can travel in MetronInfo.xml. Metron's series API already exposes all three (year_end, status, desc), and comicbox and Codex already read them from it, but no comic metadata file format can hold them today.

<Series id="65478" lang="en">
    <Name>Justice League</Name>
    ...
    <StartYear>1970</StartYear>
    <EndYear>1975</EndYear>
    <Status>Completed</Status>
    ...
    <Summary>The World's Greatest Super-Heroes unite to ...</Summary>
</Series>

Depends on #90

#90 starts the drafts/v1.2 schema, and this PR adds to that draft. The branch is stacked on #90's commit, so until #90 merges, this PR's diff includes it. The change in this PR is the last commit only (4afbd50). I'll rebase onto master once #90 is in.

The elements

All three are minOccurs="0". seriesType is an xs:all, so their order isn't enforced. They sit where a reader would look for them.

Element	Type	Placement	Metron API field
EndYear	xs:gYear	right after StartYear	year_end
Status	seriesStatusType (new enum)	after EndYear	status
Summary	xs:string	last, after AlternativeNames (long text)	desc

EndYear uses StartYear's type, xs:gYear, so the two are always read and validated the same way. I didn't add an EndYear >= StartYear assertion: XPath 2.0 doesn't define lt/ge on xs:gYear, so the assertion would have to cast the values as strings. That seemed better left to writers.

Status is a closed enumeration: Cancelled, Completed, Hiatus, Ongoing. These are exactly the Series.Status labels in comicsdb/models/series.py, which the API returns via get_status_display. The values are listed alphabetically, as formatType's are. The type is named seriesStatusType instead of statusType, so a future issue-level status won't collide with it. There is no default: if the element is absent, the status is unknown. Assuming Ongoing, which is Metron's database default, would be wrong for files tagged from other sources.

Summary (not Description or Desc): MetronInfo names elements after what they mean, not after Metron's API field names (StartYear rather than year_began, AlternativeNames rather than alt_names). The issue-level description is already <Summary>, and the issue API calls that one desc too. So mapping series desc to Series/Summary keeps a single word for "description" across the schema. Element names are already reused per parent (Publisher/Name and Series/Name), so Series/Summary next to the top-level Summary follows that precedent and is unambiguous.

Tests

The new cases use #90's TEST_V12_XSD.

• Valid: all three elements together; each of the Ongoing, Cancelled and Hiatus statuses (Completed is covered by the combined case).
• Invalid: dup_primary_attr.xml as a v1.2 baseline; status Unknown and lowercase ongoing; a two-digit EndYear; a duplicate Series/Summary; and EndYear against v1.1, which must still reject it.

Validation

• uv run pytest: 46 passed, including Add v1.2 draft schema with BCP 47 language codes #90's tests. uv run ruff check tests: clean.
• drafts/v1.2/Sample.xml validates against the v1.2 XSD with xmlschema.XMLSchema11, and is rejected by the v1.1 XSD as expected.
• The XSD Validation workflow's xmllint command passes for all three XSDs.

Docs

The element documentation on the docs site will need entries for the three elements. As with #90, that could land when v1.2 is released.

[bpepple]

When we first wrote MetronInfo.xsd, we purposely left out EndYear and Status. Their values can change (though really only for ongoing series), and Kavita, the main consumer we were targeting at the time, didn't write metadata back to files. Storing values that would go stale didn't seem very useful.

That said, I don't want MetronInfo.xsd to be so resistant to change that it stops being useful to end users. Your use case makes sense to me. A tagger could write the series information to all the issues in a series and update them when the status changes. I don't expect many users to need it, but since all three elements are optional, I'm inclined to add them, including Series/Summary. Reusing Summary to match the issue-level element seems like the right call.

We should probably have @Buried-In-Code, @jyggen, and @majora2007 weigh-in.

[ajslater]

End Year would change rarely. Ideally only once from empty to written and that doesn't seem so bad to me.
But Status could change repeatedly and that might be more troublesome.

I'm interested in reviewer opinions as well.

[jyggen]

Not a user of MetronInfo myself, but I think it all sounds reasonable. I don't think the two fields will change frequently enough for it to become a problem. Status is the only somewhat volatile one that could change multiple times during a comic's lifetime, but I guess one could simply see it as "status as of LastModified".

[Buried-In-Code]

I think the metadata files should be for static data only as you cant know if the values are accurate without checking online sources. Series summary is fine as thats not a variable field, but i dont think year end or status should be included. However having them as optional is a nice middle ground if others would like it included

[ajslater]

Feels like we need Brian to make a ruling. I don't think the fields do any harm. But I'm also happy to drop one or both of the potentially variable fields as soon as a decision is made.

At the moment I'm storing these fields to my Codex database and not writing them portably into comic archive metadata.

[bpepple]

I don't see anyone strongly opposing adding these, and I think it could be useful for some of it's consumers, so I'm fine with adding them.

I did a quick review of your proposed changes, and about the only thing I'd like to see is some validation to the end year values since we are using XSD 1.1.

[bpepple]

Looks good over all, just a couple of small items to be looked at.

[bpepple]

I did a quick look at Anilist & MangaBaka used:

• Completed: MangaBaka
• Finished: Anilist which could be mapped to Completed
• Releasing: Anilist | MangaBaka, which could be mapped to Ongoing
• Hiatus: Anilist
• Unknown: Anilist

Most of those could be mapped to this enum, the only one we might want to add is Unknown.

I'll leave it up to you whether you think we need it or not, since it would be also be valid to just not write this element if is unknown.

[bpepple]

Saw you added those assertions I mentioned. Feel free to merge this PR since I believe you've got write permissions to this repo.

We can probably make a minor release once this is merged, since I don't believe there are only other items on the horizon.

[ajslater]

Thanks. But I don't have have write access, so I can't merge.

[bpepple]

Thought we had given you permission back when we were finalizing 1.0, but guess I was wrong. Anyway, I'll go ahead and merge this. And unless you can think of any other changes we should make, I'll go ahead and release v1.2