4 ms·

Completely agree on all points. But there is something special about XML: everyone has failed to make something better.

by baz00 3y ago

dragonwriter 3y ago
> Completely agree on all points. But there is something special about XML: everyone has failed to make something better. XML’s decline from its peak of adoption mean lots of people working with data disagree with you.
alpaca128 3y ago
If you said nothing better became an industry standard I could see your point, but how exactly is XML better than s-expressions? Or, if you want something less generalized, KDL (which is roughly XML with 90% less syntax overhead)?
- baz00 3y ago
  XML has superset defined functionality of standardised schemas, transformations and query. The same is not true for s-expressions. I've not looked at KDL before but a quick scan suggests it's interesting. I will look into it.
- jerf 3y ago
  XML has a lot more defined structure than s-expressions. S-expressions make cute demos when people just take some chunk of data and blast out a conversion to drop into the conversation and hold it up as a standard, but it's not a fair comparison to take something actually defined and then splat out an undefined ad-hoc format in the spur of the moment. Of course the latter looks awesome by comparison; the example was literally structured to look awesome in this exact context. When you read the s-expression alternatives proposed to XML with an eye to "How would I actually code against this? How would I actually convince multiple people to use the exact same standard as me? How do I support all the use cases of interest to me?" they completely fall apart. They're too simple. The very fact I have to use the plural for s-expression alternative since no two of them are every quite the same says quite a bit. When you need that structure, XML is actually a very good choice; the error people made was using it when they didn't need that structure. Note how much of the complaint about using XML, even in this very conversation, is (quite correctly!) "what do I do with all these extra structural elements?" If you don't have a clear answer to that, don't use XML. If you do, don't jam it into s-exprs or JSON either, you end up with an even worse mess.
  - alpaca128 3y ago
    > How would I actually convince multiple people to use the exact same standard as me? The same way you agree on an XML schema? I don't know if I quite understand what you want to say - as I see it both are tree structured formats which means they both can represent the same information, just that s-expressions are less verbose but XML has more existing tooling for defining & validating a structure. Though the latter is more an aspect of the ecosystem than the format itself.
    - jerf 3y ago
      "The same way you agree on an XML schema?" Yes. But my point is, there's a lot of people who seem to think just waving the word "s-expression" at the problem is a solution. If you have to sit down and carefully define the exact standard, the value over XML gets mitigated a lot, because the standard is going to need a lot of stuff in it. It has to at least be as complicated as JSON, and JSON is often not quite enough. You can't just say "why don't we use s-expressions" as if that's an argument on its own. But the reality is JSON ate that space anyhow. There's no room for something that's "like JSON, but not really" anymore.

Completely agree on all points. But there is something special about XML: everyone has failed to make something better.

by baz00 3y ago

Completely agree on all points. But there is something special about XML: everyone has failed to make something better.

> Completely agree on all points. But there is something special about XML: everyone has failed to make something better. XML’s decline from its peak of adoption mean lots of people working with data disagree with you.

alpaca128 3y ago

If you said nothing better became an industry standard I could see your point, but how exactly is XML better than s-expressions? Or, if you want something less generalized, KDL (which is roughly XML with 90% less syntax overhead)?

baz00 3y ago
XML has superset defined functionality of standardised schemas, transformations and query. The same is not true for s-expressions. I've not looked at KDL before but a quick scan suggests it's interesting. I will look into it.
jerf 3y ago
XML has a lot more defined structure than s-expressions. S-expressions make cute demos when people just take some chunk of data and blast out a conversion to drop into the conversation and hold it up as a standard, but it's not a fair comparison to take something actually defined and then splat out an undefined ad-hoc format in the spur of the moment. Of course the latter looks awesome by comparison; the example was literally structured to look awesome in this exact context. When you read the s-expression alternatives proposed to XML with an eye to "How would I actually code against this? How would I actually convince multiple people to use the exact same standard as me? How do I support all the use cases of interest to me?" they completely fall apart. They're too simple. The very fact I have to use the plural for s-expression alternative since no two of them are every quite the same says quite a bit. When you need that structure, XML is actually a very good choice; the error people made was using it when they didn't need that structure. Note how much of the complaint about using XML, even in this very conversation, is (quite correctly!) "what do I do with all these extra structural elements?" If you don't have a clear answer to that, don't use XML. If you do, don't jam it into s-exprs or JSON either, you end up with an even worse mess.
- alpaca128 3y ago
  > How would I actually convince multiple people to use the exact same standard as me? The same way you agree on an XML schema? I don't know if I quite understand what you want to say - as I see it both are tree structured formats which means they both can represent the same information, just that s-expressions are less verbose but XML has more existing tooling for defining & validating a structure. Though the latter is more an aspect of the ecosystem than the format itself.
  - jerf 3y ago
    "The same way you agree on an XML schema?" Yes. But my point is, there's a lot of people who seem to think just waving the word "s-expression" at the problem is a solution. If you have to sit down and carefully define the exact standard, the value over XML gets mitigated a lot, because the standard is going to need a lot of stuff in it. It has to at least be as complicated as JSON, and JSON is often not quite enough. You can't just say "why don't we use s-expressions" as if that's an argument on its own. But the reality is JSON ate that space anyhow. There's no room for something that's "like JSON, but not really" anymore.