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
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:
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... :)