Fwd: On XML - was Fwd: [Yaml-core] Next YAML: drop equality definition
I only forward the last part of this email, since the rest is domain specific (YAML de/serialization minutiae). Z ---------- Forwarded message ---------- From: Zenaan Harkness <zen@freedbms.net> Subject: Re: [Yaml-core] Next YAML: drop equality definition On 3/10/16, Osamu TAKEUCHI <osamu@big.jp> wrote: ...
One of the reason we explicitly listed the goals, _in order_,was to break ties when different goals pushed us in different directions. Order the goals differently, and you'll get a different spec. I think you would end up with JSON if you ordered them in a different way. Or even, god help us, XML ;-) ... If we give up YAML, the next choice will indeed be XML.
Nope. The next choice will be YAML 2. Then the next choice will be JSON 1. Then the next choice will be JSON 2. Then the next choice will be native serialization in your language of choice. Then custom binary serialization. Then a continually permutating algorithmic mixing stream, just for laughs. There are infinite alternatives to XML and if worse comes to worst, I suggest hard transcoding your data into COBOL statements and serializing those in Base63. Nowhere would one willingly choose XML. Hell, I'd choose HTML if I was ordered to use XML on a project, just to make sure the next guy who touches that code knows that the serialization format has to be changed. Manager: "Z, did you finish that, what's it called again? Yeah, the XML serialization?" Me: "Sure did! And it's Netscape 3.1 compatible too." <snigger>HTML<snigger> Manager: <used to work at Best Buy, does not understand>"Oh, cool! That's just great! I knew I'd finish on time, and I'll tell marketing our new name too, 'NewScope compatible' - has a great ring to it. Great ring! Good job Z, you'll go places you know. Go places in this world!"
Actually, my library is build to replace XML serializer that is provided by C#. Since we want YAML to be able to serialize both kinds of documents, we have to think the best balance.
Should be easy. Anything's more enjoyable than XML... whoops, there I go again... :)
On Fri, Mar 11, 2016 at 2:28 PM, Zenaan Harkness <zen@freedbms.net> wrote:
Nope. The next choice will be YAML 2. Then the next choice will be JSON 1. Then the next choice will be JSON 2. Then the next choice will be native serialization in your language of choice. Then custom binary serialization. Then a continually permutating algorithmic mixing stream, just for laughs. There are infinite alternatives to XML and if worse comes to worst, I suggest hard transcoding your data into COBOL statements and serializing those in Base63.
XML is a pain to write by hand, for sure. But one shouldn't be doing that. There are perfectly good libraries for working with XML in almost every programming language. It's a bit over-engineered, but one really can represent almost any sort of data as XML. (Whether that's a good idea is a whole different question.) YAML is a lot easier to write a small file by hand, but it's kinda brittle & easy to fuck up. Not nearly as expressive as XML either. Great for small config files; imho not so great for most other things. JSON strikes a nice balance between expressiveness and human readability. That's probably why REST (or if you eschew buzzwords, JSON over HTTP) is so popular these days.
YAML is a lot easier to write a small file by hand, but it's kinda brittle & easy to fuck up. Not nearly as expressive as XML either. Great for small config files; imho not so great for most other things.
JSON strikes a nice balance between expressiveness and human readability. That's probably why REST (or if you eschew buzzwords, JSON over HTTP) is so popular these days.
Unfortunately JSON requires quotes around everything, which on English keyboards requires the same <SHIFT>+<key> keypresses as XML. Might look a little better than XML, but not a lot better for editing/ typing files...
participants (2)
-
Jason McVetta -
Zenaan Harkness