4 ms·

Never understood the typical all/nothing hivemind developer view around XML and JSON/YAML. It is and should always have been a case of horses for courses - XML

Never understood the typical all/nothing hivemind developer view around XML and JSON/YAML. It is and should always have been a case of horses for courses - XML absolutely has its uses (structured markup, mixed human readable/data islands, schema validation and multi-schema markup), yes it was bad to try to use it for everything and it is poor and long-winded for short repeated key/value item markup, but its equally bad today to treat it as passe and useless, it excels in several areas where YAML manifestly fails. Outside key/value markup of fairly shallow tree structures where schemas are singular, absent or in flux (in nosql style) or for machine consumption only, JSON/YAML is also the wrong tool to reach for.

pydry 4y ago
It was an overcomplicated design-by-committee mess. The only cases where XML tech has survived is where it got in early and inertia has kept it there and because it was "good enough". I genuinely dont know of anybody building new technology on a foundation of XML. There's always something simpler, with a lower bug surface that will handle the job better - even in its originally intended domain of document markup.
- jcon321 4y ago
  I don't know, xml represents multiline values so much better than json/yaml. Then when it comes to escaping reserved characters, wrapping it in cdata is a lot cleaner than json/yaml escaping. I am currently building something new that uses xml for a properties file. My use case requires sql inside a properties file (without the use of additional .sql files). Really wanted to use json/yaml because I felt like I was in the 90s, but xml was just a lot better for this case.
  - pydry 4y ago
    This: | Always "seemed" a lot cleaner to me. I dont see why it doesnt accomodate SQL just fine. JSON was never intended primarily for user readability. It's for sending data over a wire. Its focus was on parsing simplicity, ease of serialization and deserialization and to be incidentally readable.
    - guiriduro 4y ago
      Only works well if your text is a leaf and has no other contained entities/structure. <entity attr="whatever">Try to make this <appearance>look good</appearance> in <markup>YAML</markup></entity> As I said, horses for courses. FWIW I actually like YAML for certain limited use cases, just not where XML is better. And vice versa.
      - pydry 4y ago
        entity: attr: whatever text: |- Try to make this *look good* in **YAML**. ^ I have quite a lot of YAML hanging around these days like this. Markdown is surprisingly effective as an XML document markup replacement.
- svieira 4y ago
  Consider the case of embedding (composition is better than inheritance) data defined by a second schema inside a first schema. To quote The Zen of Python, "Namespaces are one honking great idea -- let's do more of those!". But no other format does embedding in any reasonable way (it's all ad hoc extensions on top of your serialization format).
  - pydry 4y ago
    >Consider the case of embedding (composition is better than inheritance) data defined by a second schema inside a first schema. What do you mean by this "data defined by a second schema inside a first schema"? And why is it a good idea?
    - dale_glass 4y ago
      You have a text document (eg, LibreOffice) which is XML, and want to embed a SVG in it (which is also XML). XML has tools to deal with this situation, where it knows that what's found inside <picture></picture> can be evaluated according to the SVG spec. You also have namespaces, to deal with that a <title> might be a thing both in a text document and a song, and you may need to use both inside the same document without conflicting.
  - dragonwriter 4y ago
    > Consider the case of embedding (composition is better than inheritance) data defined by a second schema inside a first schema. How, exactly, is JSON with JSON Schema inadequate for that?
- GoblinSlayer 4y ago
  There's always something simpler than xml and json, and yaml is anything but simple. They didn't try to reduce the bug surface, json tried to be parseable with eval, yaml tried to be succinct to the point of deliberate ambiguity.

pydry 4y ago

It was an overcomplicated design-by-committee mess. The only cases where XML tech has survived is where it got in early and inertia has kept it there and because it was "good enough". I genuinely dont know of anybody building new technology on a foundation of XML. There's always something simpler, with a lower bug surface that will handle the job better - even in its originally intended domain of document markup.

jcon321 4y ago
I don't know, xml represents multiline values so much better than json/yaml. Then when it comes to escaping reserved characters, wrapping it in cdata is a lot cleaner than json/yaml escaping. I am currently building something new that uses xml for a properties file. My use case requires sql inside a properties file (without the use of additional .sql files). Really wanted to use json/yaml because I felt like I was in the 90s, but xml was just a lot better for this case.
- pydry 4y ago
  This: | Always "seemed" a lot cleaner to me. I dont see why it doesnt accomodate SQL just fine. JSON was never intended primarily for user readability. It's for sending data over a wire. Its focus was on parsing simplicity, ease of serialization and deserialization and to be incidentally readable.
  - guiriduro 4y ago
    Only works well if your text is a leaf and has no other contained entities/structure. <entity attr="whatever">Try to make this <appearance>look good</appearance> in <markup>YAML</markup></entity> As I said, horses for courses. FWIW I actually like YAML for certain limited use cases, just not where XML is better. And vice versa.
    - pydry 4y ago
      entity: attr: whatever text: |- Try to make this *look good* in **YAML**. ^ I have quite a lot of YAML hanging around these days like this. Markdown is surprisingly effective as an XML document markup replacement.
svieira 4y ago
Consider the case of embedding (composition is better than inheritance) data defined by a second schema inside a first schema. To quote The Zen of Python, "Namespaces are one honking great idea -- let's do more of those!". But no other format does embedding in any reasonable way (it's all ad hoc extensions on top of your serialization format).
- pydry 4y ago
  >Consider the case of embedding (composition is better than inheritance) data defined by a second schema inside a first schema. What do you mean by this "data defined by a second schema inside a first schema"? And why is it a good idea?
  - dale_glass 4y ago
    You have a text document (eg, LibreOffice) which is XML, and want to embed a SVG in it (which is also XML). XML has tools to deal with this situation, where it knows that what's found inside <picture></picture> can be evaluated according to the SVG spec. You also have namespaces, to deal with that a <title> might be a thing both in a text document and a song, and you may need to use both inside the same document without conflicting.
- dragonwriter 4y ago
  > Consider the case of embedding (composition is better than inheritance) data defined by a second schema inside a first schema. How, exactly, is JSON with JSON Schema inadequate for that?
GoblinSlayer 4y ago
There's always something simpler than xml and json, and yaml is anything but simple. They didn't try to reduce the bug surface, json tried to be parseable with eval, yaml tried to be succinct to the point of deliberate ambiguity.