9 ms·

I have huge respect for Doug Crockford, and I never imagined I would disagree with him. However I think by now we've seen that a lot of that "unnecessary" XML

I have huge respect for Doug Crockford, and I never imagined I would disagree with him. However I think by now we've seen that a lot of that "unnecessary" XML complexity was not, in fact, entirely unnecessary. These days we use JSON for everything, but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL.

adamc 4y ago
JSON is great, but I surely wish it supported comments. That's the nature of its failings: too minimal.
- beached_whale 4y ago
  Luckily a good number of parsers support extensions to JSON like comments and trailing comma's.
- wongarsu 4y ago
  That depends on what you want it to be. For a data interchange format, having no comments is arguably a strength. For a config file format, having no comments is a big weakness.
  - sgtnoodle 4y ago
    Many people use text format protobufs for config. It vaguely resembles yaml, and the schema is enforced by virtue of requiring a message definition in order to parse it.
  - hot_gril 4y ago
    Just do { "someSetting": true "comment": "TODO change to false when ready" } Though really text-based protobufs are better for config.
    - sixbrx 4y ago
      Problems are that some tools will rewrite the file and reorder the "comment" away from what it's meant to comment on. Also might complain the "comment" item isn't expected there. I seem to remember package.json suffering from both of these under the control of npm.
      - hot_gril 4y ago
        Yeah it's definitely a limited solution, and I prefer that JSON be kept simple that way. Many package.json-adjacent configs like the Babel stuff can be in .js files, giving you comments and everything.
- keneda7 4y ago
  This always bothered me. A coworker once suggested using fields ending in 'notes' to put in comments but I never really warmed up to that.
  - rqtwteye 4y ago
    I have heard that too but it’s just a terrible idea.
- PurpleRamen 4y ago
  Comments are simple to parse, but preserving them on the dump is complex. I guess they were sacrificed for the simplicity.
  - rqtwteye 4y ago
    That’s a good point. It would be hard to read the JSON, modify it and then write back with comments. But you still should have the option to at least ignore them while reading. That would make JSON config files so much better to work with.
  - Marazan 4y ago
    They were excluded so people wouldn't use them to insert meta-processing instructions into the JSON doc. In reality people insert those meta-processing instructions in other ways.
- maxloh 4y ago
  You can use JSONC, which is JOSN with C style comments.
mgr86 4y ago
XML is pretty awesome. As a 12 year old in 1998 I remember being enthralled with it and my young mind imagined a lot of possibilities. But alas, I had no real use for it until xhtml, but even then...As the years passed I learned to drive and get the heck off my computer for a few years. It wasn't until about a decade later when I finally got to use XML "for real". At my academic publishing job. One of my first real projects was having a set of academics analyze documents in a web application I built. Prior to that they were analyzing them by hand, were converted to SGML somewhere in Korea, and we would use omnimark to move them to XML and eventually a library application. The XML community, the one's who haven't retired or passed on, have been more welcoming of the competition too. They went from XML is everywhere, to being able to return JSON from an XSLT. I am in a small shop, and so I wear many hats. But I am always satisfied when I get to work with XML, or craft an xsl/xq script that does exactly what I need. Additionally, the community as a whole is very helpful, and a bit more grey. Meaning, they are less likely to fall for trends and bullshit. A bit disjointed, but ,in short, XML is awesome. Now only if they would move Balisage back to Montreal. I'm no fan of DC or virtual conferences.
agumonkey 4y ago
What I appreciate compared to xml is: - generic concepts like arrays and maps - lack of opportunity to invent names Every xml schema is a potential DSL that reinvents things they might now. Other than that it's true that the xml era was just addressing a lot of important stuff early, I guess it was only compatible with big corp mindset and not early web dynamic / fluid / small scale apps. (a bit like how PHP started to write PSR to avoir dynamic code / effects in libs .. formalization etc.
- halostatue 4y ago
  Every JSON schema is also a potential DSL that reinvents everything. Yes, there seems to be some convergence on things, but object arrays in XML aren’t really any more complex than object arrays in JSON — there just might be multiple ways to represent them. For this JSON: { "part_numbers": [1, 2, 3, 4, 5] } You have two main ways to represent these in XML:  <order> <part_number>1</part_number> <part_number>2</part_number> <part_number>3</part_number> <part_number>4</part_number> <part_number>5</part_number> </order>  <order> <part_numbers> <part_number>1</part_number> <part_number>2</part_number> <part_number>3</part_number> <part_number>4</part_number> <part_number>5</part_number> </part_numbers> </order> Is this better than JSON? No, not particularly. But it’s no less clear than the JSON, and it compresses pretty well (it compresses better for larger documents, obviously). The larger problem with XML is that the tooling is often lacking outside of Java and C#/.NET and none of the tooling is well-built for the sort of streaming manipulation that `jq` does (it exists, but IMO one of the least usable ideas from the XML camp is XSLT), and JSON support is pretty universal everywhere, even if the advanced things like JSONpath and JSON Schema aren’t. I also think that there’s a problem when you have to choose between SAX and DOM parsing early in your process. Most JSON usage is the equivalent of using a DOM parser because the objects are expected to be relatively small, but many XML systems are built for much larger documents, and therefore need to parse the stream because the memory use otherwise would be unacceptable. The use of a JSON streaming parser is much rarer, IME.
  - treis 4y ago
wil421 4y ago
I dislike SOAP and avoid working with it when I can. However, the WSDL is an excellent part of SOAP that really makes it easier to work with. Teams tended to over engineer their APIs and all kinds of cruft would develop. I like the HTTP operations with REST. I can remember hardcoding and manipulating a bunch of non-sense legacy fields just to get a ticket created via their SOAP enterprise service bus. Not to mention all the operations that made no clear sense.
- foolfoolz 4y ago
  soap may have taken liberties with http to get its work done (graphql: so what??) but it really felt like we reinvented the wheel. i was consuming massive wsdls in 2013/2014 and i consume massive open api specs in 2023. did anything actually improve?
- haburka 4y ago
  > I dislike SOAP and avoid working with it when I can. I disagree. I think personal hygiene is very important for in-office coworking.
- tracker1 4y ago
  Unless the implementation defines too many things as just "Object" and you're consuming from a stronger typed language... and the generated library doesn't give you anything resembling a real interface. I've used a dynamic language (Node) a few times to bridge such wsdl/soap services to consume from C# and similar. Consuming SOAP/WSDL from languages other than the one it's published in isn't fun. Man, some of the PHP implementations were beyond horrible... well defined REST/RPC +_JSON is generally much easier in the end.
- tracker1 4y ago
  > I dislike SOAP and avoid working with it when I can. Well, I'm about to take a shower now, and shame on you.
davemp 4y ago
I don’t write many APIs but every JSON schema I’ve created had been automatically generated by openapi tools. Even then I’ve found schemas of very little use, because everything gets validated on deserialization anyways. Client side validation usually already taken care of in practice because users should be serializing using the same type library that deserializes or reading the docs very thoroughly. JSON is so much more ergonomic than XML as the lingua franca because I can actually read it. That being said I still have my share of problems with JSON.
- radicalbyte 4y ago
  That was the cause of the XML problems - everything was generated. Me? Schemas are a requirement in areas where you need to integrate over different technology / with different implementations. JSON Schema is in those contexts a bit of a kids toy compared to what XML can do.
  - halostatue 4y ago
    We’re using Prisma (https://prisma.io https://prisma.io) schemas for a particular data exchange project we’re doing so that we can generate JSON schemas, SQLite schemas, PostgreSQL schemas, etc. We have even found a generator to create basic Elixir code from the Prisma schemas. We’re not using anything else from Prisma, but if we had to implement something else in JS to talk to a database, that would be a contender for our database interface layer (there are only a couple of others that are even remotely usable, having suffered through the disaster of a Sequelize implementation). We’re more likely to use Elixir and Ecto.
  - taeric 4y ago
    Adding to the problems of generated schemas, Microsoft and Sun both had different views on how they should be generated. I bought into the promise of "build a wsdl" and you can get clients from .NET and Java. I lost all of that buy in. Hard. I don't know that I can lay the blame on either one of them directly, mind. But the industry definitely suffered from the bad faith cooperation of those companies.
steve1977 4y ago
… and have proper comments.
PurpleRamen 4y ago
With XML, the complexity is the baseline, and it only goes up from there. With JSON, the complexity is just an option, the baseline is pretty simple. Also, good XML-tools are rare or expensive.
- adolph 4y ago
  Here to say this too. Compositional complexity is an advantage. As a human in a repl, I appreciate the balance of readibility between XML which uses a larger set of syntactical characters, and YAML which uses fewer. I also appreciate JSON's ontological simplicity over XML. This primarily boils down to the lack of attribute nodes and explicit difference between objects (lists of key-values) and arrays (lists of values).
- kitsunesoba 4y ago
  Also this may just be the time in which I got into programming showing, but it seems like JSON encoding/decoding has been built into more languages than support for XML ever was. That's one less required dependency and thing to have to think about in many cases, like in Swift projects all I have to do is make sure my model structs/classes conform to Codable and I'm ready to hit endpoints.
  - hajile 4y ago
    That’s because writing a JSON parser is pretty straight forward with just a couple edge cases. Writing a conformant XML parser is a HUGE undertaking comparison. I could get most places to give me the time to write a JSON parser in whatever language of it didn’t have one. I couldn’t do that with XML. Because of this, every common language (and most uncommon ones) has a JSON parser while XML parsers are less common (and fully conformant ones are even more rare).
- andyjohnson0 4y ago
  Baseline for XML would be a document that doesn't use schemas, namespaces, attributes, or any of the SGML legacy stuff like DTDs and PCDATA. Such a document is essentially as simple as the equivalent JSON.
aidenn0 4y ago
I have literally never used any of these things. The hate I have for XML is the high markup overhead. Anybody who has configured a trunk of the century product with XML config files knows what I mean; the screen is usually 2/3 XML tags, which means 1/3 closing tags, which add nothing semantically
bryik 4y ago
> but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. You don't have to use any of those.
- halostatue 4y ago
  You don’t have to use anything for XML, either. The simplest XML document is almost indistinguishable from the simplest JSON document. Nothing in XML requires XML schemas or namespaces or anything else that is usually attributed to the complexities of XML.
bilalq 4y ago
The ambiguity difference around lists alone makes JSON over XML compelling. It is simpler than XML/XSD. Without the schema, you never know if a certain element should be treated as being part of a list or not. When interoperating with anything other than XML, that matters.
dylan604 4y ago
I have to say that I was bit disappointed the first time I learned about JSON Schema. My immediate reaction was to wonder if they were trying to become XML.
irrational 4y ago
> but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL. Uh... do we? I've never used any of those. Plain JSON has always worked fine for me.
throwawaymaths 4y ago
OpenAPI is complex not because of JSON, but because it's a nearly complete description of http.

adamc 4y ago

JSON is great, but I surely wish it supported comments. That's the nature of its failings: too minimal.

beached_whale 4y ago
Luckily a good number of parsers support extensions to JSON like comments and trailing comma's.
wongarsu 4y ago
That depends on what you want it to be. For a data interchange format, having no comments is arguably a strength. For a config file format, having no comments is a big weakness.
- sgtnoodle 4y ago
  Many people use text format protobufs for config. It vaguely resembles yaml, and the schema is enforced by virtue of requiring a message definition in order to parse it.
- hot_gril 4y ago
  Just do { "someSetting": true "comment": "TODO change to false when ready" } Though really text-based protobufs are better for config.
  - sixbrx 4y ago
    Problems are that some tools will rewrite the file and reorder the "comment" away from what it's meant to comment on. Also might complain the "comment" item isn't expected there. I seem to remember package.json suffering from both of these under the control of npm.
    - hot_gril 4y ago
      Yeah it's definitely a limited solution, and I prefer that JSON be kept simple that way. Many package.json-adjacent configs like the Babel stuff can be in .js files, giving you comments and everything.
keneda7 4y ago
This always bothered me. A coworker once suggested using fields ending in 'notes' to put in comments but I never really warmed up to that.
- rqtwteye 4y ago
  I have heard that too but it’s just a terrible idea.
PurpleRamen 4y ago
Comments are simple to parse, but preserving them on the dump is complex. I guess they were sacrificed for the simplicity.
- rqtwteye 4y ago
  That’s a good point. It would be hard to read the JSON, modify it and then write back with comments. But you still should have the option to at least ignore them while reading. That would make JSON config files so much better to work with.
- Marazan 4y ago
  They were excluded so people wouldn't use them to insert meta-processing instructions into the JSON doc. In reality people insert those meta-processing instructions in other ways.
maxloh 4y ago
You can use JSONC, which is JOSN with C style comments.

mgr86 4y ago

XML is pretty awesome. As a 12 year old in 1998 I remember being enthralled with it and my young mind imagined a lot of possibilities. But alas, I had no real use for it until xhtml, but even then...As the years passed I learned to drive and get the heck off my computer for a few years. It wasn't until about a decade later when I finally got to use XML "for real". At my academic publishing job. One of my first real projects was having a set of academics analyze documents in a web application I built. Prior to that they were analyzing them by hand, were converted to SGML somewhere in Korea, and we would use omnimark to move them to XML and eventually a library application. The XML community, the one's who haven't retired or passed on, have been more welcoming of the competition too. They went from XML is everywhere, to being able to return JSON from an XSLT. I am in a small shop, and so I wear many hats. But I am always satisfied when I get to work with XML, or craft an xsl/xq script that does exactly what I need. Additionally, the community as a whole is very helpful, and a bit more grey. Meaning, they are less likely to fall for trends and bullshit. A bit disjointed, but ,in short, XML is awesome. Now only if they would move Balisage back to Montreal. I'm no fan of DC or virtual conferences.

agumonkey 4y ago

What I appreciate compared to xml is: - generic concepts like arrays and maps - lack of opportunity to invent names Every xml schema is a potential DSL that reinvents things they might now. Other than that it's true that the xml era was just addressing a lot of important stuff early, I guess it was only compatible with big corp mindset and not early web dynamic / fluid / small scale apps. (a bit like how PHP started to write PSR to avoir dynamic code / effects in libs .. formalization etc.

halostatue 4y ago
Every JSON schema is also a potential DSL that reinvents everything. Yes, there seems to be some convergence on things, but object arrays in XML aren’t really any more complex than object arrays in JSON — there just might be multiple ways to represent them. For this JSON: { "part_numbers": [1, 2, 3, 4, 5] } You have two main ways to represent these in XML:  <order> <part_number>1</part_number> <part_number>2</part_number> <part_number>3</part_number> <part_number>4</part_number> <part_number>5</part_number> </order>  <order> <part_numbers> <part_number>1</part_number> <part_number>2</part_number> <part_number>3</part_number> <part_number>4</part_number> <part_number>5</part_number> </part_numbers> </order> Is this better than JSON? No, not particularly. But it’s no less clear than the JSON, and it compresses pretty well (it compresses better for larger documents, obviously). The larger problem with XML is that the tooling is often lacking outside of Java and C#/.NET and none of the tooling is well-built for the sort of streaming manipulation that `jq` does (it exists, but IMO one of the least usable ideas from the XML camp is XSLT), and JSON support is pretty universal everywhere, even if the advanced things like JSONpath and JSON Schema aren’t. I also think that there’s a problem when you have to choose between SAX and DOM parsing early in your process. Most JSON usage is the equivalent of using a DOM parser because the objects are expected to be relatively small, but many XML systems are built for much larger documents, and therefore need to parse the stream because the memory use otherwise would be unacceptable. The use of a JSON streaming parser is much rarer, IME.
- treis 4y ago

wil421 4y ago

I dislike SOAP and avoid working with it when I can. However, the WSDL is an excellent part of SOAP that really makes it easier to work with. Teams tended to over engineer their APIs and all kinds of cruft would develop. I like the HTTP operations with REST. I can remember hardcoding and manipulating a bunch of non-sense legacy fields just to get a ticket created via their SOAP enterprise service bus. Not to mention all the operations that made no clear sense.

foolfoolz 4y ago
soap may have taken liberties with http to get its work done (graphql: so what??) but it really felt like we reinvented the wheel. i was consuming massive wsdls in 2013/2014 and i consume massive open api specs in 2023. did anything actually improve?
haburka 4y ago
> I dislike SOAP and avoid working with it when I can. I disagree. I think personal hygiene is very important for in-office coworking.
tracker1 4y ago
Unless the implementation defines too many things as just "Object" and you're consuming from a stronger typed language... and the generated library doesn't give you anything resembling a real interface. I've used a dynamic language (Node) a few times to bridge such wsdl/soap services to consume from C# and similar. Consuming SOAP/WSDL from languages other than the one it's published in isn't fun. Man, some of the PHP implementations were beyond horrible... well defined REST/RPC +_JSON is generally much easier in the end.
tracker1 4y ago
> I dislike SOAP and avoid working with it when I can. Well, I'm about to take a shower now, and shame on you.

davemp 4y ago

I don’t write many APIs but every JSON schema I’ve created had been automatically generated by openapi tools. Even then I’ve found schemas of very little use, because everything gets validated on deserialization anyways. Client side validation usually already taken care of in practice because users should be serializing using the same type library that deserializes or reading the docs very thoroughly. JSON is so much more ergonomic than XML as the lingua franca because I can actually read it. That being said I still have my share of problems with JSON.

radicalbyte 4y ago
That was the cause of the XML problems - everything was generated. Me? Schemas are a requirement in areas where you need to integrate over different technology / with different implementations. JSON Schema is in those contexts a bit of a kids toy compared to what XML can do.
- halostatue 4y ago
  We’re using Prisma (https://prisma.io https://prisma.io) schemas for a particular data exchange project we’re doing so that we can generate JSON schemas, SQLite schemas, PostgreSQL schemas, etc. We have even found a generator to create basic Elixir code from the Prisma schemas. We’re not using anything else from Prisma, but if we had to implement something else in JS to talk to a database, that would be a contender for our database interface layer (there are only a couple of others that are even remotely usable, having suffered through the disaster of a Sequelize implementation). We’re more likely to use Elixir and Ecto.
- taeric 4y ago
  Adding to the problems of generated schemas, Microsoft and Sun both had different views on how they should be generated. I bought into the promise of "build a wsdl" and you can get clients from .NET and Java. I lost all of that buy in. Hard. I don't know that I can lay the blame on either one of them directly, mind. But the industry definitely suffered from the bad faith cooperation of those companies.

steve1977 4y ago

… and have proper comments.

PurpleRamen 4y ago

With XML, the complexity is the baseline, and it only goes up from there. With JSON, the complexity is just an option, the baseline is pretty simple. Also, good XML-tools are rare or expensive.

adolph 4y ago
Here to say this too. Compositional complexity is an advantage. As a human in a repl, I appreciate the balance of readibility between XML which uses a larger set of syntactical characters, and YAML which uses fewer. I also appreciate JSON's ontological simplicity over XML. This primarily boils down to the lack of attribute nodes and explicit difference between objects (lists of key-values) and arrays (lists of values).
kitsunesoba 4y ago
Also this may just be the time in which I got into programming showing, but it seems like JSON encoding/decoding has been built into more languages than support for XML ever was. That's one less required dependency and thing to have to think about in many cases, like in Swift projects all I have to do is make sure my model structs/classes conform to Codable and I'm ready to hit endpoints.
- hajile 4y ago
  That’s because writing a JSON parser is pretty straight forward with just a couple edge cases. Writing a conformant XML parser is a HUGE undertaking comparison. I could get most places to give me the time to write a JSON parser in whatever language of it didn’t have one. I couldn’t do that with XML. Because of this, every common language (and most uncommon ones) has a JSON parser while XML parsers are less common (and fully conformant ones are even more rare).
andyjohnson0 4y ago
Baseline for XML would be a document that doesn't use schemas, namespaces, attributes, or any of the SGML legacy stuff like DTDs and PCDATA. Such a document is essentially as simple as the equivalent JSON.

aidenn0 4y ago

I have literally never used any of these things. The hate I have for XML is the high markup overhead. Anybody who has configured a trunk of the century product with XML config files knows what I mean; the screen is usually 2/3 XML tags, which means 1/3 closing tags, which add nothing semantically

bryik 4y ago

> but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. You don't have to use any of those.

halostatue 4y ago
You don’t have to use anything for XML, either. The simplest XML document is almost indistinguishable from the simplest JSON document. Nothing in XML requires XML schemas or namespaces or anything else that is usually attributed to the complexities of XML.

bilalq 4y ago

The ambiguity difference around lists alone makes JSON over XML compelling. It is simpler than XML/XSD. Without the schema, you never know if a certain element should be treated as being part of a list or not. When interoperating with anything other than XML, that matters.

dylan604 4y ago

I have to say that I was bit disappointed the first time I learned about JSON Schema. My immediate reaction was to wonder if they were trying to become XML.

irrational 4y ago

> but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL. Uh... do we? I've never used any of those. Plain JSON has always worked fine for me.

throwawaymaths 4y ago

OpenAPI is complex not because of JSON, but because it's a nearly complete description of http.