Cockatrice: Allow markup tags in Cockatrice set files

[ancestral]

Cockatrice refuses to load cards from set files which contain uppercase tags. For example, <I> where italic text exists on a card will fail, and the rest of the cards from the file is not imported.

Could Cockatrice allow for uppercase tags, or allow this be case insensitive?

[ZeldaZach]

Well that's stupid... thought XML was CI already

[ancestral]

Turns out XML isn’t, but XML Schema Definition Language 1.1 supports an assertion to force elements to lowercase.

[Daenyth]

<I> in card text isn't valid, you should be encoding it with CDATA https://stackoverflow.com/questions/2784183/what-does-cdata-in-xml-mean?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

[ctrlaltca]

Related: #3112

[ancestral]

@Daenyth That’s not what I am looking for.

I do want to encode the bold or italic tags here. Elements or tags could happen to use uppercase instead of lowercase as HTML tags such as <B> can use uppercase.

Perhaps it’s not a bug; in which case, this is a feature request then that I’m asking for.

[ancestral]

One bad card will result in Cockatrice aborting the whole set. At the very least, other things that could be done are displaying an error message and skipping the bad card and continuing on to the next one.

[ctrlaltca]

I do want to encode the bold or italic tags here. Elements or tags could happen to use uppercase instead of lowercase as HTML tags such as <B> can use uppercase.

Both uppercase and lowercase tags work. I just tested the example i provided on #3112 with an uppercase tag.
If Cockatrice fails to load a set, that's due to the xml not being well formatted. A badly encoded tag is a possible (probable) culprit.

displaying an error message and skipping the bad card

An xml parser is usually not able to "fix" a broken xml structure by only skipping the broken part. Due to the nature of xml, once the parser encounters a not-correctly closed tag, it's not able to guess the structure present in the text following the error.

[ancestral]

It appears this is larger than I thought. Markup elements are not currently supported at all.

An XML file with markup such as <i> is not invalid or malformed. I’ll attach a file with one card that has an <i> in it. The file is valid XML.
03.DAD.xml.txt

I’m okay with the client not handling the italics or bold, for example. I’m happy if it doesn’t style the words. I just don’t want the import to fail.

[ctrlaltca]

It appears this is larger than I thought. Markup elements are not currently supported at all.

Either I don't understand what you mean, or you didn't see the example at #3112 with bold text.

An XML file with markup such as <i> is not invalid or malformed

An XML schema is not like html where you can happily add tags around. Cockatrice declares a specific xml schema for card database files, and either the file follows it or Cockatrice won't be able to load it. You can find the schema here: https://github.com/Cockatrice/Cockatrice/blob/master/doc/cards.xsd
How to use it: https://github.com/Cockatrice/Cockatrice/wiki/Custom-Cards-&-Sets#i-modified-my-cardsxml-and-it-isnt-working-properly

I just don’t want the import to fail.

You need to encode text contents using entities or CDATA
This has nothing to do with tags, but every character that is used internally by xml in its structure needs to be properly encoded.

[ancestral]

Alright, I think I understand. Sorry for the confusion. 😞

Just so I understand, the schema isn’t tied into the parser, correct? That is, I don’t see any references to the schema in the Cockatrice code, checks or any libraries that utilize the schema specifically. It appears it’s just for personal reference? (Or is it used in Servatrice?)

Anyway, I’m told there was a refactor with the parser in 2.5.1. So I think I may have found some bugs, then. I attributed this to an issue with style markup tags, but I was certainly wrong. I apologize; I was actually just encountering issues with the 2.5.1 parser, which I’ll break down here:

In 2.5.0, if you are importing a set file with an unknown element, Cockatrice ignores it, and moves on to the next element (hopefully as intended?) In 2.5.1, the parser fails on the unknown element, and aborts the rest of the import.

I would hope 2.5.1 would ignore the invalid elements if possible, as it did in 2.5.0. Seeing that the code just looks for specific elements to capture anyway (name, type, text, etc.) I can’t imagine a specific issue there. However, I guess if you are after a stricter importing, then it may be acceptable to skip the card and simply continue? But at the very least, displaying an error message indicating there actually was a problem would be very helpful. (I recently made a Cockatrice set file for folks to use, and I assumed it worked correctly as I saw a bunch of cards in the database. It was only after people told me they were missing cards did I even realize anything bad actually happened.)

In the schema, do we need xs:sequence with those card elements? I feel like xs:all would be fine; I don’t know of an importance to the order of the card elements.

And it may be good to update the wiki with any recent changes. I found this page personally helpful when I built my Cockatrice exporter from my own web card editor. (I can help with that if you’d like.)

I am totally willing to create new issues for any of this. Just let me know how I can help 👍🏼

[Daenyth]

Definitely make new issues for specific problems you run into. And the wiki is publicly editable, feel free to add your own notes where it's helpful.

Right now the parser isn't using the xsd; probably down the line we will autogenerate some parser code from the xsd. Right now it's mainly for validating custom files. If your custom file is valid with xmllint and cockatrice doesn't handle it right, I'd consider that a bug in either the xsd or cockatrice.