Why does ACME use JSON, arrrg! I know XML is a pain, but surely that would have been better. I need to knock up a JSON library now :-) The plan is for @firebrick to have ACME @letsencrypt built in - not in this coming release of code but next one, soon...— RevK® (@TheRealRevK) 7 April 2018
Well, I am starting to wonder if JSON is better than XML in some ways now. I have coded a new JSON library for the FireBrick today. It was not hard, in fact, the simplicity does make me wonder if neater in some ways than XML.
Both have a clear formal spec, but what do they have different?
- XML has all sorts of special cases like CDATA and processing instructions and comments, JSON does not
- XML does not allow a null character even escaped, JSON allows it
- XML has all of that pesky namespace stuff. It has its place but for a lot of systems it does not help matters and makes it more complex
- XML has no concept of even simply types for data, JSON has strings, numbers, boolean, and null as distinct and identifiable types.
- XML only has objects with attributes and sub objects, JSON has arrays which XML does not.
The JSON library was actually really easy and the syntax if very strict, surprisingly so, to be honest.
So I am leaning towards JSON as being better than XML for now.
What is this all in aid of? Well FireBricks use code we control and we have coded everything from operating system startup to IPSec. So I needed to make a JSON library. There are "standard" open source libraries we could use, but having only taken a day to do this I suspect integrating something in to our build system would have taken longer.
But why do I need JSON all of a sudden? Well ACME uses JSON, and I am working on ACME coding to allow FireBricks to easily have Let's Encrypt certificates for https. So I start with a JSON library.
A good days work I think.
Yeah, give me JSON over XML any day!
ReplyDelete+1. XML is horrible and JSON is a joy to work with by comparison, with no shortage of great libraries and tools that make using it effortless.
ReplyDeleteWe have one FireBrick and while I'm quite happy with it and largely impressed, the main thing putting me off getting more is the use of XML, which brings about flashbacks to indulgently Byzantine enterprise software hell. Bizarrely, I think I'd rather you used some mad binary representation entirely of your own making than XML.
We have tried to be nice with the xml though. Not strict on order of different objects and so on. No messing with namespaces (we include in output anyway). But I see your point. Ironically, making the config available and usable as JSON as well would not be hard. Maybe we’ll do that one day. It maps to internal structure.
DeleteYes, but you're missing the obvious solution, all the benefits of JSON with the Enterprisiness of XML: https://www.ibm.com/support/knowledgecenter/en/SS9H2Y_7.1.0/com.ibm.dp.doc/json_jsonx.html
ReplyDeletePlease be careful. Introducing input processing vulnerabilities is very easy when you write your own parsing code.
ReplyDeleteI know... :-)
DeleteI tend to use yaml libraries to read json quite often - this is a superset of json (so a yaml interpreter will read json fine), and has a few useful things like you can add comments to your json files and it'll just ignore them.
ReplyDeleteThe other useful thing is json schemas, which gives you an equivalent to xsd files for XML - they work well and I find them much easier to write than xsds...
XML has always struck me as being so horribly wordy, whereas JSON is just a text representation of a recursive Python list and dictionary structure. In fact that's exactly what you get with the Python JSON parser.
ReplyDeleteAnother upvote for json here. Its easy to generate without libraries and I've yet to find a language that doesn't have at least one parser library. It makes generating dynamic data for web page javascript far easier than XML ever could and providing its well formatted its totally human readable. :)
ReplyDelete