3 ms·

The nuance that differentiates my example is I’m not picking some random web page (where html might actually make sense to use) and trying to apply json to a do

by mlazos 8y ago

The nuance that differentiates my example is I’m not picking some random web page (where html might actually make sense to use) and trying to apply json to a domain it most certainly is not optimized for. I’m taking an extremely common case and showing why xml is way too verbose for very simple scenarios. My main point is in xml the closing tags are unnecessary, and you need an opening tag for every value where it’s obvious from nested context what that value is supposed to be. Xml is very redundant, there’s just all this zero entropy text everywhere which conveys no information. I disagree with your metadata in json example, why not just add more data to the value? The data model of msbuild is also annoying, but I’ve worked with some dotnet core projects now and using json as the project format definitely saves typing and actually allows you to intuit what a project is doing rather than just bombarding you with useless text.

manigandham 8y ago
.NET Core uses .csproj project files which are XML. Do you have difficulty in reading a large HTML document? That's as verbose and repetitive as XML but also usually filled with junk comments and malformed tags. If you don't find it hard, then why is XML different?
int_19h 8y ago
You're picking a particular way to handle that common case. A common way, I agree, but you have others if verbosity is what you're optimizing for. And with respect to data and metadata, what you propose is not fundamentally different in terms of verbosity: <foo metadata="bar">baz</foo> { "foo": {"value": "baz", "metadata": "bar"} } And it's even worse if you also need to preserve order of keys.
- mlazos 8y ago
  Ok, but like what if your metadata is even more complicated than just a single field, it’s ridiculous to have to include even more opening and closing tags. <map> <kvp> <key>k</key> <value>v</key> <metadata> <field1>m</field1> <field2>m2</field2> </metadata> </kvp> </map> It’s just crazy to look at tbh, and it was annoying to type on my phone. I’m amazed people are still arguing in favor of it. In reality you just want the markup to transmit the most information in the least amount of bits. This is a measurable quantity and xml objectively sucks at it.
  - int_19h 8y ago
    > In reality you just want the markup to transmit the most information in the least amount of bits. If that were the case, we'd be using binary serialization everywhere. But you yourself are making an argument that ease of writing matters. So does ease of reading. Overly verbose markup is a tax on both, but so is extreme brevity. Anyway, this particular thread was a discussion to address a very specific point made in the article that overstated XML verbosity over JSON. I'm not actually arguing that XML is perfect, or even "good enough". Its syntax is overly verbose, and its data model has pointless distinctions and arbitrary restrictions. But it also had many good ideas, and it's unfortunate that those get ignored in the quest of simplifying everything - and then later, when the issues that were the original motivation for those ideas are rediscovered, that wheel gets reinvented in dozens of flawed and mutually incompatible ways.

by mlazos 8y ago

manigandham 8y ago

.NET Core uses .csproj project files which are XML. Do you have difficulty in reading a large HTML document? That's as verbose and repetitive as XML but also usually filled with junk comments and malformed tags. If you don't find it hard, then why is XML different?

int_19h 8y ago

You're picking a particular way to handle that common case. A common way, I agree, but you have others if verbosity is what you're optimizing for. And with respect to data and metadata, what you propose is not fundamentally different in terms of verbosity: <foo metadata="bar">baz</foo> { "foo": {"value": "baz", "metadata": "bar"} } And it's even worse if you also need to preserve order of keys.

mlazos 8y ago
Ok, but like what if your metadata is even more complicated than just a single field, it’s ridiculous to have to include even more opening and closing tags. <map> <kvp> <key>k</key> <value>v</key> <metadata> <field1>m</field1> <field2>m2</field2> </metadata> </kvp> </map> It’s just crazy to look at tbh, and it was annoying to type on my phone. I’m amazed people are still arguing in favor of it. In reality you just want the markup to transmit the most information in the least amount of bits. This is a measurable quantity and xml objectively sucks at it.
- int_19h 8y ago
  > In reality you just want the markup to transmit the most information in the least amount of bits. If that were the case, we'd be using binary serialization everywhere. But you yourself are making an argument that ease of writing matters. So does ease of reading. Overly verbose markup is a tax on both, but so is extreme brevity. Anyway, this particular thread was a discussion to address a very specific point made in the article that overstated XML verbosity over JSON. I'm not actually arguing that XML is perfect, or even "good enough". Its syntax is overly verbose, and its data model has pointless distinctions and arbitrary restrictions. But it also had many good ideas, and it's unfortunate that those get ignored in the quest of simplifying everything - and then later, when the issues that were the original motivation for those ideas are rediscovered, that wheel gets reinvented in dozens of flawed and mutually incompatible ways.