ID Element Alternative Schema

[bpepple]

Starting a discussion whether we want to modify the ID element to something like AJ suggested over in the Matrix chatroom.

In the schema, the ID element currently looks like:

<IDS>
    <ID source="Metron" primary="true">1043</ID>
    <ID source="Comic Vine">169037</ID>
</IDS>

AJ's suggestion would look like this:

<IDS>
    <ID nid="metron.cloud" nss="1043" url="https://metron.cloud/issue/richard-starks-parker-2009-1/" primary="true" />
    <ID nid="comicvine.gamespot.com" nss="169037"
            url="https://comicvine.gamespot.com/richard-starks-parker-1-the-hunter/4000-169037/"/>
</IDS>

This schema layout would solve the problem of a source not being included in our informationSource enumeration, but does make the element fairly bulky since some of the URLS could be quick long depending on the website.

Looking at it a bit... I'm not sure if the benefits out-way it's deficits, but would be interested in hearing other folks thoughts.

[majora2007]

While it doesn't look good, it is much more functional and a metadata doesn't really need to look good.

[bpepple]

I probably should have clarified what I saw as the deficiencies of using a urn-style for the ID element, so off the top of my head I see the following issues:

• Added Complexity: Consumers (Kavita, Codex, etc) and possibly Providers (dependent on how they write to file) of the xml document would most likely need to add some form of regexing the identifiers like AJ does with comicbox to handle situations like where the document has "comicvine.com", "comicvine.gamespot.com" or some other value. It could also make adoption a bit harder, since adding to support to existing apps (for example, comictagger) would need a decent amount of work.
• URL: For my 2¢, I wouldn't have the url be in the ID element, but if it was, does it make sense to have a URLS element? If not, how would you handle situations where the url is only tangentially related to the comic? Would we want to lump that in under the IDS parent?
• Stylist Change: If we use a urn-style for the ID elements, it would make sense for the rest of the xsd (characters, team, etc) to follow suit. If this was done, we could most likely drop the primary attributes since it would be redundant.

Now with that said, I'm not totally opposed to the idea since there are some clear benefits, but it is a fairly big change to the xsd as a whole.

[majora2007]

After giving it some more thoughts, I don't think this is a move we should make for the spec. It is completely different than the way the rest of the spec is designed. We did have an "Other" implementation already designed for situations that fall outside the major metadata providers.

As you mentioned, switching to the urn style is a major change and would signal that we should refactor the existing spec to match. This would delay finalization. This also does suffer from domain name changes breaking metadata mappings due to the way the nid works.

[bpepple]

I vacillate between the two, but tend to think the drawbacks outweigh the benefit of using a urn-style xsd.

I know @Buried-In-Code wants to comment on this issue when he gets some free time, so maybe he'll have a compelling argument for switching.

[Buried-In-Code]

Until this discussion I hadn't heard about urn, so had to do a bit of research to see what it was about. When I thought about linking the ids and the urls, I thought it would keep more or less the current scheme just with an extra attribute or element for the url. But after looking at the discussion and the way to implement it, I don't think we should.

I agree with all 3 points @bpepple made:

1. I prefer the use of enums instead of urls to make the id identifable, but if we want flexibility in future I'd be ok with a "Other" Source enum value for edge cases.
2. Same as what was said.
3. After looking and testing something like this out I prefer to have the bulk of the id/sources in 1 element and just using the id for characters/creators/etc... so it keeps the info cleaner looking

[bpepple]

Alright, so it sounds like we're in agreement to keep the current ID handling and not switch to urn-style.

With that decided, I suggest we do the following:

• Add Additional Source Enums: I was doing some research and noticed Comic-Tagger had additional plugins for kitsu.io, mangadex, and MangaUpdates, which I believe we should also add to our information enumerations.
• Add Documentation: We need to add documentation on how to handle information sources that aren't in the source enumerations, this could be a simple note saying to add a URL element and mark the primary attribute as true.

[rad96]

Who cares about URL length in file no one supposed to look with eyes at? 🤔

P.S. And it's funny for me that the only service where you can't access an entity web page by "ID only" is Metron (and League, but I don't count them because they don't have an API, don't planning on it's implementation and so you can't tag stuff with their link), so you can't "generate" url to web page from ID only, you need to do some work afaik

[bpepple]

A lot of users do manually tag their files.

[rad96]

I, actually, don't know. I don't :)
But you probably right, as I never asked

[majora2007]

I also haven't heard of many users manually tagging with a text editor, however manually done via a GUI, for sure. I'm in that boat.

[bpepple]

Spent a little time today working on a branch on what this change would potentially look like. Right now, not including the URL the xml would look like this:

https://github.com/Metron-Project/metroninfo/blob/urn-style/drafts/v1.0/Sample.xml

One thing I don't like, is that I'm not aware of a way to make sure if an element has a nid attribute that it also has an nss attribute. This scenario would be for the Characters, Arc, etc. elements since source information is optional.

[bpepple]

Did a little research today and I think something like this should fix the problem I referenced above:

<xs:complexType name="resourceType">
    <xs:simpleContent>
        <xs:extension base="xs:string">
            <xs:attribute name="nid" type="xs:string" />
            <xs:attribute name="nss" type="xs:string" />
            <xsd:assert test="(@nid and @nss) or (not(@nid) and not(@nss))"/>
        </xs:extension>
    </xs:simpleContent>
</xs:complexType>