anansi-project / comicinfo

ComicInfo.xml's new home
https://anansi-project.github.io/docs/category/comicinfo
MIT License
136 stars 8 forks source link

Multiple Story Arcs for one Comic #43

Closed ajslater closed 1 year ago

ajslater commented 1 year ago

Where does this comes from?

<StoryArc /> and <StoryArcNumber /> exist, but assume that the comic can be a member of zero or one story arc.

I propose that the schema change to:

Example:

<StoryArc number="23">
  Cosmo Eats Galactus
</StoryArc>
<StoryArc number="4">
  Galactus Gets Eaten
</StoryArc>
<StoryArc>
 The Silver Surfer Gets Lunch
</StoryArc>

We don't know the number for "The Silver Surfer Gets Lunch" so the display software would have to find some other way to order comics with that StoryArc, publication date is often close.

Something like this:

<xs:element minOccurs="0" maxOccurs="unbounded" name="StoryArc" type="xs:string">
    <xs:attribute name="number" type="xs:int" use="optional" />
</xs:element>

(forgive me if my schema declaration isn't perfect, but you get the idea)

What is the rationale for adding support for this element?

Comics are often a part of multiple story arcs. This would allow an expression of this within the ComicInfo.xml metadata.

I imagine that software could read Reading List formats, match them to comics with GTIN or by fuzzy logic or manual means and then encode those reading lists into the comics themselves.

This has a pretty good portability benefit. And should be simple to scan for comic readers.

The downside of encoding story arc and number into comics is that re-ordering them in the case of a mistake or change requires editing the metadata of many comics and introduces the possibility of partial information. Like two comics labeled #47 for the same story arc. Story Arc spelling variations, etc. Different opinions on story arc inclusion and order, etc.

Is the element already handled by any application or tool?

This would replace <StoryArc /> and <StoryArcNumber />

gotson commented 1 year ago

The problem with that change is that it would be breaking.

We had the discussion on Mylar's discord, and the consensus was that no comics are part of multiple reading orders. Is that change related to actual comics being part of multiple reading orders, or purely theoritical?

ajslater commented 1 year ago

I confess it's theoretical. I suppose multiple StoryArc tags might be breaking as the clients will only expect one.

evilhero just told me that Mylar's fork of comictagger does a subencoding hack with json stuffed into the fields.

StoryArc: {"arc1", "arc2"} 
StoryArcNumber: {5, 12}

Where the mapping for arcs to orders is implicit in the json ordering. Ugly, and then StoryArcNumber is not an xs:int, but would get the job done. If, as you point out, it's a job that needs doing.

I should probably join the readlist channels to talk about stuff like this as I'm new to it.