6 ms·

We had that a decade ago. It was called XML and XML Schema. All IDEs support it. JSON was a huge step backwards in the name of simplicity. And now when we are

by pookeh 6y ago

We had that a decade ago. It was called XML and XML Schema. All IDEs support it. JSON was a huge step backwards in the name of simplicity. And now when we are going to add similar functionality to JSON, something else is going to come out in the name of simplicity (like NestedText).

thaumaturgy 6y ago
Magento is a popular codebase that made XML-based configuration a fundamental part of its architecture. The results were terrible and caused numerous headaches and countless hours lost to trying to troubleshoot inscrutable configuration issues. The Magento 2 codebase began a shift away from XML for configuration, although it still uses some. There may be room for an argument that Magento did XML badly (it did many things badly), but I don't believe I've ever seen XML done well.
- vbezhenar 6y ago
  I love XML configuration in Spring.
  - imtringued 6y ago
    I don't get it. The @Configuration and @Bean annotations are at least 100 times more readable and powerful than whatever garbage people used to write into their xml files to define beans. 20 lines of xml are often equivalent to like 8 lines of Java and each of those Java lines is shorter than the xml equivalent. Repeating closing tags is not very interesting.
m463 6y ago
I think XML sort of failed simplicity. In a minute I can read and write json from most languages I use. In the same amount of time, I'm still wondering if I should use a tag or attribute in xml. cdata? expat? It's not that xml isn't a good technology. It's that it's not appropriate for general use, especially in comparison to simpler alternatives.
- vbezhenar 6y ago
  If your child node has unique name among its siblings and does not contain nested nodes, then it's an attribute. Otherwise it's an element. Seems pretty obvious to me. The fundamental issue with XML is its impedance mismatch with common data structures which forces using Object to XML mappers (whether explicitly or implicitly). It's more or less solved with XML Schemas or DTDs, but if you're looking at just XML, you can't tell whether some element is an array or a single node. Thus JSON is better suited for serialization.
  - quietbritishjim 6y ago
    > If your child node has unique name among its siblings and does not contain nested nodes, then it's an attribute. Otherwise it's an element. Seems pretty obvious to me. That is really not what attributes are for. I feel a bit of a fraud posting that because I'm not an XML expert and so not really clear what they actually are for. (This reenforces the parent's point: you need to be an expert to know what such a fundamental feature is for.) I remember it's something like "something used to help interpret the actual value" e.g. units of measurement. But most of the time, even if it's non-repeating with no children, you're supposed to use elements rather than attributes. One problem here is that attributes are so much more compact (and so often easier to read) than elements that it's tempting to use them in places where you ought to use an element (and many people over time have given in to that temptation). Another problem is that the distinction between attributes and elements is almost never useful. That was the parent comment's point by the looks of things. > The fundamental issue with XML is its impedance mismatch with common data structures That's probably part of it, but I think at least as problematic is that it has many features that most of the time you don't need and don't want to have to care about. Things like CDATA (also mentioned by the parent comment), custom entities, external entities, DTDs (which can be inline in XML files so you need to know all about DTDs to understand XML properly). That's why there are all sorts of weird XML vulnerabilities that JSON doesn't have. Did you know you can make an XML file that reads your /etc/passwd file when it's parsed? That is not an issue with JSON.
    - sergeykish 6y ago
kanox 6y ago
We have it today for JSON, it's called JSON Schema and many IDEs support it.
- tda 6y ago
  Exactly, jsonschema allows one to describe exactly how the json should look like including inter field validation. And with tools like reactjsonschemaform you can generate a ui on top of it for free.
jeffbee 6y ago
XML is fatally flawed because you can't safely put one XML doc inside another one. Because of this rather fundamental problem, it never was any good for anything, and it never will be.
- tootie 6y ago
  XInclude works pretty well.
- vbezhenar 6y ago
  I don't understand why can't you safely put one XML doc inside another one? Many XML formats are literally built using this feature, like SOAP.
  - jeffbee 6y ago
    SOAP was and is an epic disaster, so that hardly seems like a refutation. The known way to embed an entire XML doc into a SOAP message was to use CDATA, which isn't a general solution because it means the embedded doc can't have ]]> in it anywhere. You could also base64-encoded the included doc. Both of these solutions and all other known solutions to this problem are, as I'm sure you can see, just awful. You can't just paste XML in XML because of the <?xml?> thing, because of entities, and because of half a dozen other misfeatures of XML.
    - jiggawatts 6y ago
      You miss the point entirely. You put XML fragments inside a parent XML document using namespaces. This is very well supported, and used extensively. Trying to "escape" XML to nest it in a parent XML document is Wrong with a capital W.
      - uryga 6y ago
        > You put XML fragments inside a parent XML document using namespaces. could you post or link to an example? i'm not very familiar with advanced XML features or for a simple example: what would it look like to put `child` into `parent` using namespaces? # parent-doc.xml <parent>  </parent> # child-doc.xml <child x=3 y=5/>
Netch 6y ago
> We had that a decade ago. It was called XML and XML Schema. It would be true if XML was not full of all this SGML debris like "entities" (really, uncontroller macros), if real schema formats was flexible enough (I needed <c> inside <a> and <c> inside <b> when they totally different), etc. But when a config reader tool has to deal with 40+-year legacy of enterprise guys wanting to embrace the universe, but all this doesn't allow to control contents without external measures like regexp checking... that simply shuts up facing real world.
irrational 6y ago
I spent years working with xml, xslt, xml schema. Frankly when I first saw json I thought it was terrific. Nothing has changed my mind since. Why do you feel like it is a huge step backwards?
atombender 6y ago
JSON Schema [1] is actually a mature standard now, with decent tooling support, mostly through OpenAPI (formerly Swagger), which extends it with support for endpoints. It's much simpler to use than XML Schemas, and arguably results in cleaner data models, since it doesn't have anything analogous to XML namespaces that allow for arbitrary mixing of schemas. [1] https://json-schema.org/ https://json-schema.org/

by pookeh 6y ago

thaumaturgy 6y ago

Magento is a popular codebase that made XML-based configuration a fundamental part of its architecture. The results were terrible and caused numerous headaches and countless hours lost to trying to troubleshoot inscrutable configuration issues. The Magento 2 codebase began a shift away from XML for configuration, although it still uses some. There may be room for an argument that Magento did XML badly (it did many things badly), but I don't believe I've ever seen XML done well.

vbezhenar 6y ago
I love XML configuration in Spring.
- imtringued 6y ago
  I don't get it. The @Configuration and @Bean annotations are at least 100 times more readable and powerful than whatever garbage people used to write into their xml files to define beans. 20 lines of xml are often equivalent to like 8 lines of Java and each of those Java lines is shorter than the xml equivalent. Repeating closing tags is not very interesting.

m463 6y ago

I think XML sort of failed simplicity. In a minute I can read and write json from most languages I use. In the same amount of time, I'm still wondering if I should use a tag or attribute in xml. cdata? expat? It's not that xml isn't a good technology. It's that it's not appropriate for general use, especially in comparison to simpler alternatives.

vbezhenar 6y ago
If your child node has unique name among its siblings and does not contain nested nodes, then it's an attribute. Otherwise it's an element. Seems pretty obvious to me. The fundamental issue with XML is its impedance mismatch with common data structures which forces using Object to XML mappers (whether explicitly or implicitly). It's more or less solved with XML Schemas or DTDs, but if you're looking at just XML, you can't tell whether some element is an array or a single node. Thus JSON is better suited for serialization.
- quietbritishjim 6y ago
  > If your child node has unique name among its siblings and does not contain nested nodes, then it's an attribute. Otherwise it's an element. Seems pretty obvious to me. That is really not what attributes are for. I feel a bit of a fraud posting that because I'm not an XML expert and so not really clear what they actually are for. (This reenforces the parent's point: you need to be an expert to know what such a fundamental feature is for.) I remember it's something like "something used to help interpret the actual value" e.g. units of measurement. But most of the time, even if it's non-repeating with no children, you're supposed to use elements rather than attributes. One problem here is that attributes are so much more compact (and so often easier to read) than elements that it's tempting to use them in places where you ought to use an element (and many people over time have given in to that temptation). Another problem is that the distinction between attributes and elements is almost never useful. That was the parent comment's point by the looks of things. > The fundamental issue with XML is its impedance mismatch with common data structures That's probably part of it, but I think at least as problematic is that it has many features that most of the time you don't need and don't want to have to care about. Things like CDATA (also mentioned by the parent comment), custom entities, external entities, DTDs (which can be inline in XML files so you need to know all about DTDs to understand XML properly). That's why there are all sorts of weird XML vulnerabilities that JSON doesn't have. Did you know you can make an XML file that reads your /etc/passwd file when it's parsed? That is not an issue with JSON.
  - sergeykish 6y ago

kanox 6y ago

We have it today for JSON, it's called JSON Schema and many IDEs support it.

tda 6y ago
Exactly, jsonschema allows one to describe exactly how the json should look like including inter field validation. And with tools like reactjsonschemaform you can generate a ui on top of it for free.

jeffbee 6y ago

XML is fatally flawed because you can't safely put one XML doc inside another one. Because of this rather fundamental problem, it never was any good for anything, and it never will be.

tootie 6y ago
XInclude works pretty well.
vbezhenar 6y ago
I don't understand why can't you safely put one XML doc inside another one? Many XML formats are literally built using this feature, like SOAP.
- jeffbee 6y ago
  SOAP was and is an epic disaster, so that hardly seems like a refutation. The known way to embed an entire XML doc into a SOAP message was to use CDATA, which isn't a general solution because it means the embedded doc can't have ]]> in it anywhere. You could also base64-encoded the included doc. Both of these solutions and all other known solutions to this problem are, as I'm sure you can see, just awful. You can't just paste XML in XML because of the <?xml?> thing, because of entities, and because of half a dozen other misfeatures of XML.
  - jiggawatts 6y ago
    You miss the point entirely. You put XML fragments inside a parent XML document using namespaces. This is very well supported, and used extensively. Trying to "escape" XML to nest it in a parent XML document is Wrong with a capital W.
    - uryga 6y ago
      > You put XML fragments inside a parent XML document using namespaces. could you post or link to an example? i'm not very familiar with advanced XML features or for a simple example: what would it look like to put `child` into `parent` using namespaces? # parent-doc.xml <parent>  </parent> # child-doc.xml <child x=3 y=5/>

Netch 6y ago

> We had that a decade ago. It was called XML and XML Schema. It would be true if XML was not full of all this SGML debris like "entities" (really, uncontroller macros), if real schema formats was flexible enough (I needed <c> inside <a> and <c> inside <b> when they totally different), etc. But when a config reader tool has to deal with 40+-year legacy of enterprise guys wanting to embrace the universe, but all this doesn't allow to control contents without external measures like regexp checking... that simply shuts up facing real world.

irrational 6y ago

I spent years working with xml, xslt, xml schema. Frankly when I first saw json I thought it was terrific. Nothing has changed my mind since. Why do you feel like it is a huge step backwards?

atombender 6y ago

JSON Schema [1] is actually a mature standard now, with decent tooling support, mostly through OpenAPI (formerly Swagger), which extends it with support for endpoints. It's much simpler to use than XML Schemas, and arguably results in cleaner data models, since it doesn't have anything analogous to XML namespaces that allow for arbitrary mixing of schemas. [1] https://json-schema.org/ https://json-schema.org/