Should 'text' of a vanilla card be "" and not a missing key?
bakert opened this issue · comments
I think from a theoretical standpoint a card like Jhessian Lookout does have oracle text, it's just that its oracle text is empty. But we don't send the key or a value in the json for vanilla cards (or at least for Jhessian Lookout). That feels slightly wrong?
What makes me think this is worth changing apart from a slight possible theoretical incorrectness is (a) handling a missing key on the client end is harder than handling the expected key with an empty value, and (b) it would probably be dead easy.
Is there a reason we don't send the key with empty string as the value? If not I'll go ahead and send a PR.
The code I'm using to workaround this on the other end in my particular case is:
# mtgjson thinks the text of Jhessian Lookout is NULL not ''.
if c.get('text', None) is None and c['layout'] in ['normal', 'token', 'double-faced', 'split', 'aftermath']:
c['text'] = ''
Agreed. If any cards shouldn't have the "text" key, it would be un-cards, not vanilla cards.
What about basic lands?
I consider those vanilla cards.
To me basic lands don't have text. When I think about that, it leads me to wonder more about whether vanilla creatures have blank text or don't have text.
From a data schema standpoint, it is entirely reasonable for text to be an optional field. Whether it should be optional or required is something that should be determined by the semantics of the data, not by one particular use case.
From a data storage standpoint, adding "text": "", to every blank card is a non-trivial increase in the total amount of data that our json files take up. We should be sure the semantics and convenience are worth it before we add a lot of empty data.
@bakert could you use a more blanket get when dealing with text fields? In my Python that uses mtgjson, I frequently treat optional fields by defining the default that I want: card.get('text', '')
I think giving all cards that have a defined oracle text, even if that text is empty, the "text" field is a step in the right direction given that we can then determine that a card doesn't have oracle text (because it's an un-card) from the lack of the "text" field. I'm aware that these cards currently do have "text", but they shouldn't.
What about basic lands?
Even older basic lands don't have oracle text on gatherer:
http://gatherer.wizards.com/Pages/Card/Details.aspx?printed=false&multiverseid=8335
Well... they have Card Text: R
Technically, Basic Lands should probably have "({T}: Add {M} to your mana pool.)"
@silasary Basic lands very explicitly do not have any rules text (or for this discussion have blank rules text).
"({T}: Add {M} to your mana pool.)" is reminder text, which is sometimes present on the printed card but is not present in the oracle text.
Basic lands receive their mana abilities because of Rule 305.6. This is why cards like Urborg, Tomb of Yawgmoth and Blood Moon work without setting card text.
This is important because it means that Magical Hack can change the color a land is able to produce by changing its basic land type, whereas Magical Hack cannot change the color of mana produced by a card like Tranquil Thicket that derives its mana ability from text instead of from rule 305.6.
I think I can agree that "vanilla cards" can have an empty text key. We will not put text into this field that is in parenthesis, as we have determined this to not be necessary earlier in the MTGJSON history.
If cards with no text are given an empty text field, it should be consistent. Colorless cards should then also have an empty "colors" array, cards without a mana cost should have the empty string, etc. I don't think that's really necessary though- it's easy enough to add the properties you need on your end.
And cards should absolutely not have an empty string if they're in a normal set and a null string if they're from an unset- that's just a horrible mess of a system.
Let's agree that consistency is the top goal. It would be better to leave everything as-is than implement something piecemeal. I'm happy to apply that not just to rules text but to attributes that it makes sense to ask for from every magic card.
The strongest argument I see for missing values is the case of cards with no mana cost (think Hypergenesis). Here the absence/null represents not "we don't know" but "there is nothing to know". One could then by analogy make an argument that a card with no oracle text has a similar absence of rules text. And that cards with no colors have an absence of colors, etc.
I think the argument for empty values rather than nulls is pretty obvious. It's not that we don't know the rules text of Jhessian Lookout it's that it's empty. Which could pretty happily be represented by an empty string. It's not that you can't ask for the color of a colorless card it's just that the value is an empty list, etc. The no mana cost case feels slightly different to me but again an empty string could be our representation of "no mana cost" as opposed to "we don't know" (null) as our representation of mana cost is as a string.
So, I can argue it both ways, but one way requires less work of the client programmer and the other requires our files to get larger. I assume zip/gzip makes the size increase basically irrelevant for all practical purposes. So I like the empty values. If someone wants to post and say "that would be a giant waste of your time in order to save two lines in your program that uses mtgjson and would break X or Y or Z elsewhere" then I'll drop it. If not I'll go ahead and put together a PR :)
I don't see the issue with cards with no cost having the empty string. It's exactly the same as cards with no oracle text having the empty string, or cards with no color having the empty array.
The problem with this approach is, as specified above, the file size. It's not just about the size of the downloaded zip file- it also affects the speed of whatever you're doing with the file after you decompress it.
Also, some characteristics really don't need to be specified- are you going to include "Loyalty: 0" on all non-planeswalker cards?
I'd say that Grizzly Bears has a rules text of '' (that's a sensible question but there's nothing to say) and a loyalty of NULL (that's not a sensible question for this card). I think "no loyalty key present" represents the NULL loyalty of a Grizzly Bears well but I find it weird to represent "that's a sensible question but I have nothing to say" for rules text. Basically I'd only apply this behavior to properties that every card has.
If we think that the larger files is a real issue for performance or backwards compatibility I'm happy to drop it and continue working around it.
How much of a file size increase (compressed and uncompressed) or potential performance loss are we actually talking for AllCards, AllSets and AllSets-x for example...
The proposal for uncards is moot now that they do have oracle text.
In V4, there is "text": ""