Open jakem742 opened 2 years ago
The BookCollection construct seems to be what you describe.
Under the current model, does all info about the relevant collections, series etc get stored within each book?
The model is just that, a model. It does not (yet) describe how to export part of the model into a file, akin to what Comicinfo.xml does. That would come at a later stage.
Is that the original intent of the BookCollection construct, or are there other types of Collections that this is meant to encompass as well? Do all collections necessarily have an order to them?
Ok, so this model is meant to contain absolutely everything associated with books, series etc. That makes sense.
This seems to have been touched on briefly in #3, but doesn't seem to be incorporated into the data structure in any way.
I want to propose a new link to the "Book" structure called "StoryArc". Each Book would be "part of" 0...* different StoryArc structures. Each StoryArc contains a string for title.
There would need to be a StoryArcEntry containing an int for readingOrderNumber.
The readingOrderNumber may change depending on user's manual modifications to the reading list, so not sure if it's as simple as I've described above. Unless this system contains a single readingOrderNumber as the absolute source of truth that can't be modified (I imagine modifications to the reading order would then need to be handled by each specific app, rather than within this structure).
Under the current model, does all info about the relevant collections, series etc get stored within each book? Or is the intention to reference specific collection/series/storyarc id's which contain more info about these objects. I imagine each tagged file needs to be completely self-contained without dependence on external structures, however it doesn't seem efficient to try and keep everything within the book.