I was curious how each format would look when using actual crossfire data. So, I made this webpage to show it! https://shjohnson314.com/cf/format-compare/
I show the following side-by-side: Current, YAML, XML, JSON, TOML using an example of formulae descriptions. I also included pros and cons for each (as objective as possible). If most people don't mind the whitespace dependency, then I most prefer YAML, otherwise XML. When creating the examples, I noticed the following problems with JSON: - Does not allow comments (as I said above, though Nicolas suggested including them as part of our data) In the example I show "data-comments" for the whole file and individual items. I also include regular comments that don't belong to a particular object (except in JSON). - Does not allow multiline strings This is what makes me dislike JSON for this use case. We can't include comments or "data-comments" that are more than one line (easily/nicely). Anything else that is more than one line (messages, books) would look bad too in JSON. Because of these problems with JSON, my next favorite would be XML. I included TOML only because it came up in comparisons between different file formats. It's simple but I couldn't get formula ingredients nicely formatted. TOML does not allow arrays with different types. If I got some pros or cons wrong please let me know. Steven H Johnson On Tue, Dec 21, 2021 at 12:08 PM Nicolas Weeger <nicolas.wee...@laposte.net> wrote: > Hello. > > > > Since XML is a subset (superset?) of SGML, I think finding and > > incorporating an XML parser is much easier than a SGML one. > > Probably, yes. > > > I think the biggest tug of war would be between JSON and XML. I would > > likely lean toward JSON, since it's more compact. > > Both are good enough in my eyes, so I guess it'll depend on who actually > writes the first code :) > > > > I think it's important that editing tools are more or less ironclad > > before making a big change. As hard as it is to learn to make and > > submit new/changed content, I'd hate to see it get more intimidating > > through adoption of new formats. > > Well, some people find modifying text files intimidating, I guess... Yes > tools > should be as ironclad as possible, but bugs happen... Besides, a good text > editor nowadays will handle JSON or XML without too much hassle, so > changing > manually would still be possible. > > > > Overall, I'll be sad to see a departure from the current flat files, > > though I acknowledge that the need for something more "standard" is > > legitimate. > > Well, you can always write a parser generator :) > > Given the flat text format definition (in what language?), a generator > that'll > write a parser (and writer) for it. > > Then we can keep the flat files :D > > > Best regards > > > Nicolas_______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > IRC: http://crossfire.real-time.com/irc/index.html > Discord: http://crossfire.real-time.com/discord/index.html > Project Site: https://sourceforge.net/projects/crossfire/ > Wiki: http://wiki.cross-fire.org/ > Website: http://crossfire.real-time.com >
_______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire IRC: http://crossfire.real-time.com/irc/index.html Discord: http://crossfire.real-time.com/discord/index.html Project Site: https://sourceforge.net/projects/crossfire/ Wiki: http://wiki.cross-fire.org/ Website: http://crossfire.real-time.com
