Don’t drink the JSON coolaid. XML is fine. Better, in many cases, because XML files actually support comments.
In the modern programming world, XML is just JSON before JSON was cool. There was a whole hype about XML for a few years, which is why old programming tools are full of XML.
It’s funny but sad to see the JSON ecosystem scramble to invent all of the features that XML already had. Even ActivityPub runs on “external entities but stored as general purpose strings”, and don’t get me started on the incompatible, incomplete standards for describing a JSON schema.
It’s not just XML either, now there’s cap’n proto and protobuf and bson which are all just ASN.1 but “cool”.
SOAP requires reading a manual before you get started, but so do the frameworks that try to replace it. APIs are APIs, you rarely need to manually access any of the endpoints unless the backend doesn’t stick to the rules (and what good do any alternatives provide if that happens?) or your language of choice somehow still lacks code generators for WSDL files.
OpenAPI/Swagger is just SOAP reincarnate. The code generators seem to be a bit more modern, but that’s about it really.
I came into the industry right when XML fever had peaked as was beginning to fall back. But in MS land, it never really went away, just being slowly cannibalize by JSON.
You’re right though, there was some cool stuff being done with xml when it was assumed that it would be the future of all data formats. Being able to apply standard tools like XLT transforms, XSS styling, schemas to validate, and XPath to search/query and you had some very powerful generic tools.
JSON has barely caught up to that with schemes and transforms. JQ lets you query json but I don’t really find it more readable or usable than XPath. I’m sure something like XLT exists, but there’s no standardization or attempt to rally around shared tools like with XML.
That to me is the saddest thing. VC/MBA-backed companies have driven everyone into the worst cases of NIHS ever. Now there’s no standards, no attempts to share work or unify around reliable technology. Its every company for themselves and getting other people suckered into using (and freely maintaining) your tools as a prelude to locking them into your ecosystem is the norm now.
I have actually seen it in an XML file in the wild. Never quite understood why they did it. Anything they encoded into there, they could have just added a node for.
But it was an XML format that was widely used in a big company, so presumably somewhere someone wrote a shitty XML parser that can’t deal with additional nodes. Or they were just scared of touching the existing structure, I don’t know.
IMHO: XML is a file format, JSON is a data transfer format. Reinventing things like RSS or SVG to use JSON wouldn’t be helpful, but using XML to communicate between your app’s frontend and backend wouldn’t be either.
Most web frameworks contain code to exchange JSON over XMLHttpRequest for a reason. XML is and always has been a data transfer format as well as a file format. JSON is, too. The amount of config.jsons I’ve had to mess with…
but using XML to communicate between your app’s frontend and backend wouldn’t be either
I don’t see why not? The entrypoint of web frontends is sent as HTML already. I guess that’s based on SGML, XML’s weird and broken cousin. Outputting XML is just a matter of configuring whatever model serialiser from JSON to XML.
There are a few good arguments against XML, but those also work against JSON.
Of course you can use XML that way, but it is unnecessarily verbose and complex because you have to make decisions, like, whether to store things as attributes or as nested elements.
I stand by my statement that if you’re saving things to a file you should probably use XML, if you’re transferring data over a network you should probably use JSON.
Of course you can use XML that way, but it is unnecessarily verbose and complex because you have to make decisions, like, whether to store things as attributes or as nested elements.
That’s a rather annoying shortcoming of XML, I agree. Then again, the choice is pretty inconsequential and the XSD for your data exchange format will lift any ambiguity anyway.
The choice between XML and JSON are a matter of preference, nothing more. XML is much more powerful than JSON and it’s usually a better choice in my opinion, but if you’re writing your applications well, you may as well be sending your data as pixels in a PNG because your serialiser/deserialiser should be dealing with the file format anyway.
XSDs are far from perfect, but waaay more powerful than json schema.
XSLT has its problems, but completely transforming a document to a completely different structure with just a bit of text is awesome. I had to rewrite a relatively simple XSLT in Java and it was something like 10 times more lines.
XSD and XSLT files alone can replace half the JSON applications I’ve seen. I can see why it’s easier to take the barebones JSON notation and reinvent the wheel, but those tiny programs are the “Excel+VBA” of web applications.
Please don’t. If you need something like json but with comments, then use YAML or TOML. Those formats are designed to be human-readable by default, json is better suited for interchanging information between different pieces of software. And if you really need comments inside JSON, then find a parser that supports // or /* */ syntax.
Yes, it’s a field. Specifically, a field containing human-readable information about what is going on in adjacent fields, much like a comment. I see no issue with putting such information in a json file.
As for “you don’t comment by putting information in variables”: In Python, your objects have the __doc__ attribute, which is specifically used for this purpose.
Don’t drink the JSON coolaid. XML is fine. Better, in many cases, because XML files actually support comments.
In the modern programming world, XML is just JSON before JSON was cool. There was a whole hype about XML for a few years, which is why old programming tools are full of XML.
It’s funny but sad to see the JSON ecosystem scramble to invent all of the features that XML already had. Even ActivityPub runs on “external entities but stored as general purpose strings”, and don’t get me started on the incompatible, incomplete standards for describing a JSON schema.
It’s not just XML either, now there’s cap’n proto and protobuf and bson which are all just ASN.1 but “cool”.
People may hate on SOAP but I’ve never had issues with setting up a SOAP client
SOAP requires reading a manual before you get started, but so do the frameworks that try to replace it. APIs are APIs, you rarely need to manually access any of the endpoints unless the backend doesn’t stick to the rules (and what good do any alternatives provide if that happens?) or your language of choice somehow still lacks code generators for WSDL files.
OpenAPI/Swagger is just SOAP reincarnate. The code generators seem to be a bit more modern, but that’s about it really.
I came into the industry right when XML fever had peaked as was beginning to fall back. But in MS land, it never really went away, just being slowly cannibalize by JSON.
You’re right though, there was some cool stuff being done with xml when it was assumed that it would be the future of all data formats. Being able to apply standard tools like XLT transforms, XSS styling, schemas to validate, and XPath to search/query and you had some very powerful generic tools.
JSON has barely caught up to that with schemes and transforms. JQ lets you query json but I don’t really find it more readable or usable than XPath. I’m sure something like XLT exists, but there’s no standardization or attempt to rally around shared tools like with XML.
That to me is the saddest thing. VC/MBA-backed companies have driven everyone into the worst cases of NIHS ever. Now there’s no standards, no attempts to share work or unify around reliable technology. Its every company for themselves and getting other people suckered into using (and freely maintaining) your tools as a prelude to locking them into your ecosystem is the norm now.
That’s my biggest peev about JSON actually. No comments!! WTH!
On one hand I agree, on the other hand I just know that some people would immediately abuse it and put relevant data into comments.
do they do that in xml? never seen that
I have actually seen it in an XML file in the wild. Never quite understood why they did it. Anything they encoded into there, they could have just added a node for.
But it was an XML format that was widely used in a big company, so presumably somewhere someone wrote a shitty XML parser that can’t deal with additional nodes. Or they were just scared of touching the existing structure, I don’t know.
This is why there are none, but I still think it’s dumb. Parsers can’t see comments anyways.
That’s assuming people actually use a parser and don’t build their own “parser” to read values manually.
And before anyone asks: Yes, I’ve known people who did exactly that and to this day I’m still traumatized by that discovery.
But yes, comments would’ve been nice.
There’s comments in the specs and a bunch of parsers that actually inore //
I don’t see comments in the spec?
json spec draft 7
IMHO: XML is a file format, JSON is a data transfer format. Reinventing things like RSS or SVG to use JSON wouldn’t be helpful, but using XML to communicate between your app’s frontend and backend wouldn’t be either.
Most web frameworks contain code to exchange JSON over
XMLHttpRequestfor a reason. XML is and always has been a data transfer format as well as a file format. JSON is, too. The amount ofconfig.jsons I’ve had to mess with…I don’t see why not? The entrypoint of web frontends is sent as HTML already. I guess that’s based on SGML, XML’s weird and broken cousin. Outputting XML is just a matter of configuring whatever model serialiser from JSON to XML.
There are a few good arguments against XML, but those also work against JSON.
Of course you can use XML that way, but it is unnecessarily verbose and complex because you have to make decisions, like, whether to store things as attributes or as nested elements.
I stand by my statement that if you’re saving things to a file you should probably use XML, if you’re transferring data over a network you should probably use JSON.
That’s a rather annoying shortcoming of XML, I agree. Then again, the choice is pretty inconsequential and the XSD for your data exchange format will lift any ambiguity anyway.
The choice between XML and JSON are a matter of preference, nothing more. XML is much more powerful than JSON and it’s usually a better choice in my opinion, but if you’re writing your applications well, you may as well be sending your data as pixels in a PNG because your serialiser/deserialiser should be dealing with the file format anyway.
Yeah, json is not a good config format. As much as xml is not. Please use something like YAML or TOML.
I never moved away from ini I’ve just been sititng back watching you all re-invent the wheel over and over and over and over and over.
It’s a wheel, it’s supposed to turn over and over and over ad infinitum!
/S (because it’s big sarcasm instead of small.)
We were using XML for that before JSON.
Yes and it is a good thing we don’t anymore.
Why? JSON hasn’t given us anything XML hasn’t, except maybe a bit of terseness.
I do agree SOAP is a bit over engineered, though, but that’s not the fault of XML.
XML is much more annoying to read/write by hand
As a pentester, if I see XML in HTTP I start crying.
And there are some truly magic tools.
XSDs are far from perfect, but waaay more powerful than json schema.
XSLT has its problems, but completely transforming a document to a completely different structure with just a bit of text is awesome. I had to rewrite a relatively simple XSLT in Java and it was something like 10 times more lines.
And don’t forget about namespaces. Look at formats like HAL and ODATA that try to add HATEOAS onto JSON.
XSD and XSLT files alone can replace half the JSON applications I’ve seen. I can see why it’s easier to take the barebones JSON notation and reinvent the wheel, but those tiny programs are the “Excel+VBA” of web applications.
Please don’t. If you need something like json but with comments, then use YAML or TOML. Those formats are designed to be human-readable by default, json is better suited for interchanging information between different pieces of software. And if you really need comments inside JSON, then find a parser that supports
//or/* */syntax.That’s not a comment, that’s a field. There’s a reason
var comment = "Increments i by 1"isn’t how you comment in any programs.Yes, it’s a field. Specifically, a field containing human-readable information about what is going on in adjacent fields, much like a comment. I see no issue with putting such information in a json file.
As for “you don’t comment by putting information in variables”: In Python, your objects have the
__doc__attribute, which is specifically used for this purpose.