4 ms·

XML is perfect. + With all the fancy editors now its very easy to write. Easy schema to check, comments. Perfect.

by zz865 5y ago

nsonha 5y ago
not easy to read, it's the java of config, pages of code that express very little, by the time you find what you need, you forget the context and what level of nesting you're on already. It's also more wasteful as a transport.
- KronisLV 5y ago
  > It's also more wasteful as a transport. This is most certainly true, however with GZip thrown into the mix, it's not quite as bad as one might imagine: https://www.codeproject.com/articles/604720/json-vs-xml-some-hard-numbers-about-verbosity https://www.codeproject.com/articles/604720/json-vs-xml-some... It compresses pretty decently and doesn't have too much of an overhead, in the example it being around 10% larger than JSON when compressed. I'd argue that if one were to swap out JSON for XML within all the requests that an average webpage needs for some unholy reason, the overall increase in page size would be much less than that, because huge amounts of modern sites are images, as well as bits of JS that won't be executed but also won't be removed because our tree shaking isn't perfect. Edit: as someone who writes a good deal of Java in their dayjob, i feel like commenting about the verbosity of XML might be unwelcome. I'll only say that in some cases it can be useful to have elements that have been structured and described in verbose ways, especially when you don't have the slightest idea about what API or data you're looking at when seeing it for the first time (the same way how WSDL files for SOAP could provide discoverability). However, it all goes downhill due to everything looking like a nail once you have a hammer - most of the negative connotations with XML in my mind actually come from Java EE et al and how it tried doing dynamic code loading through XML configuration (e.g. web.xml, context.xml, server.xml and bean configuration), which was unpleasant. On an unrelated note, XSD is the one truly redeeming factor of XML, the equivalent of which for JSON took a while to get there (JSON Schema). Similarly, WSDL was a good attempt, whereas for JSON there first was WADL which didn't gain popularity, though at least now OpenAPI seems to have a pretty stable place, even if the tooling will still take a while to get there (e.g. automatically generating method stubs for a web API with a language's HTTP client).
  - BerislavLopac 5y ago
    You mean something like https://pyotr.readthedocs.io https://pyotr.readthedocs.io
    - KronisLV 5y ago
      Thanks for the link, but not necessarily. How WSDL and the code generation around it worked, was that you'd have a specification of the web API (much like OpenAPI attempts to do), which you could feed into any number of code generators, to get output code which has no coupling to the actual generator at runtime, whereas Pyotr is geared more towards validation and goes into the opposite direction: https://pyotr.readthedocs.io/en/latest/client/ https://pyotr.readthedocs.io/en/latest/client/ The best analogy that i can think of is how you can also do schema first application development - you do your SQL migrations (ideally in an automated way as well) and then just run a command locally to generate all of the data access classes and/or models for your database tables within your application. That way, you save your time for 80% of the boring and repetitive stuff while minimizing the risks of human error and inconsistencies, with nothing preventing you from altering the generated code if you have specific needs (outside of needing to make it non overrideable, for example, a child class of a generated class). Of course, there's no reason why this can't be applied to server code either - write the spec first and generate stubs for endpoints that you'll just fill out. Similarly there shouldn't be a need for a special client to generate stubs for OpenAPI, the closest that Python in particular has for now is this https://github.com/openapi-generators/openapi-python-client https://github.com/openapi-generators/openapi-python-client However, for some reason, model driven development never really took off, outside of niche frameworks, like JHipster: https://www.jhipster.tech/ https://www.jhipster.tech/ Furthermore, for whatever reason formal specs for REST APIs also never really got popular and aren't regarded as the standard, which to me seems silly: every bit of client code that you write will need a specific version to work against, which should be formalized.
      - BerislavLopac 5y ago
        Well, in Python, code generation is an anti-pattern.
- GoblinSlayer 5y ago
  >you forget the context Wait, it the opposite. XML is designed to indicate context, and JSON is designed to hide context, you have a bunch of braces in place of context there, no matter where you are it's braces all the way down, like lisp.
  - nsonha 5y ago
    not really, what enables you to have the context is shorter code. It's useless to have context reminders at the top and bottom of the thing, but not the middle and it's too damn long
eitland 5y ago
Disclaimer: this is not a defense for YAML, I'm just trying to remove the rose tinted glasses some people view XML configs through. As someone who has used XML configs they have a few problems: - technical: missing comments are mentioned multiple times here so I will mention that while XML has comments they cannot be nested. - socially: for some reason (maybe because XML is structured enough that this doesn't immediately collapse?) XML tends to just grow and grow. People start programming in XML too, and not only using XSLT or other standard approaches but also in completely proprietary ways. At one project someone even wrote an authorization framework in Apache Tiles which allowed one to create roles using somewhere between 600 and 5000 lines of XML pr role. The benefit was of course that you could update the roles without touching the Java code. (In case it isn't immediately obvious: it would have been extremely much simpler to edit it in Java, and people who know enough Java to fix it are available at the right price, the XML system had to be learned at work.) Personally I just want it to be kept simple: - a settings.local.ini and default settings in settings.ini or something to that effect - if necessary, just use a code file: config.ts works just as well, or config.js if it needs to be adjustable at runtime without transpilation.

XML is perfect. + With all the fancy editors now its very easy to write. Easy schema to check, comments. Perfect.

by zz865 5y ago

XML is perfect. + With all the fancy editors now its very easy to write. Easy schema to check, comments. Perfect.

not easy to read, it's the java of config, pages of code that express very little, by the time you find what you need, you forget the context and what level of nesting you're on already. It's also more wasteful as a transport.

KronisLV 5y ago
> It's also more wasteful as a transport. This is most certainly true, however with GZip thrown into the mix, it's not quite as bad as one might imagine: https://www.codeproject.com/articles/604720/json-vs-xml-some-hard-numbers-about-verbosity https://www.codeproject.com/articles/604720/json-vs-xml-some... It compresses pretty decently and doesn't have too much of an overhead, in the example it being around 10% larger than JSON when compressed. I'd argue that if one were to swap out JSON for XML within all the requests that an average webpage needs for some unholy reason, the overall increase in page size would be much less than that, because huge amounts of modern sites are images, as well as bits of JS that won't be executed but also won't be removed because our tree shaking isn't perfect. Edit: as someone who writes a good deal of Java in their dayjob, i feel like commenting about the verbosity of XML might be unwelcome. I'll only say that in some cases it can be useful to have elements that have been structured and described in verbose ways, especially when you don't have the slightest idea about what API or data you're looking at when seeing it for the first time (the same way how WSDL files for SOAP could provide discoverability). However, it all goes downhill due to everything looking like a nail once you have a hammer - most of the negative connotations with XML in my mind actually come from Java EE et al and how it tried doing dynamic code loading through XML configuration (e.g. web.xml, context.xml, server.xml and bean configuration), which was unpleasant. On an unrelated note, XSD is the one truly redeeming factor of XML, the equivalent of which for JSON took a while to get there (JSON Schema). Similarly, WSDL was a good attempt, whereas for JSON there first was WADL which didn't gain popularity, though at least now OpenAPI seems to have a pretty stable place, even if the tooling will still take a while to get there (e.g. automatically generating method stubs for a web API with a language's HTTP client).
- BerislavLopac 5y ago
  You mean something like https://pyotr.readthedocs.io https://pyotr.readthedocs.io
  - KronisLV 5y ago
    Thanks for the link, but not necessarily. How WSDL and the code generation around it worked, was that you'd have a specification of the web API (much like OpenAPI attempts to do), which you could feed into any number of code generators, to get output code which has no coupling to the actual generator at runtime, whereas Pyotr is geared more towards validation and goes into the opposite direction: https://pyotr.readthedocs.io/en/latest/client/ https://pyotr.readthedocs.io/en/latest/client/ The best analogy that i can think of is how you can also do schema first application development - you do your SQL migrations (ideally in an automated way as well) and then just run a command locally to generate all of the data access classes and/or models for your database tables within your application. That way, you save your time for 80% of the boring and repetitive stuff while minimizing the risks of human error and inconsistencies, with nothing preventing you from altering the generated code if you have specific needs (outside of needing to make it non overrideable, for example, a child class of a generated class). Of course, there's no reason why this can't be applied to server code either - write the spec first and generate stubs for endpoints that you'll just fill out. Similarly there shouldn't be a need for a special client to generate stubs for OpenAPI, the closest that Python in particular has for now is this https://github.com/openapi-generators/openapi-python-client https://github.com/openapi-generators/openapi-python-client However, for some reason, model driven development never really took off, outside of niche frameworks, like JHipster: https://www.jhipster.tech/ https://www.jhipster.tech/ Furthermore, for whatever reason formal specs for REST APIs also never really got popular and aren't regarded as the standard, which to me seems silly: every bit of client code that you write will need a specific version to work against, which should be formalized.
    - BerislavLopac 5y ago
      Well, in Python, code generation is an anti-pattern.
GoblinSlayer 5y ago
>you forget the context Wait, it the opposite. XML is designed to indicate context, and JSON is designed to hide context, you have a bunch of braces in place of context there, no matter where you are it's braces all the way down, like lisp.
- nsonha 5y ago
  not really, what enables you to have the context is shorter code. It's useless to have context reminders at the top and bottom of the thing, but not the middle and it's too damn long

eitland 5y ago

Disclaimer: this is not a defense for YAML, I'm just trying to remove the rose tinted glasses some people view XML configs through. As someone who has used XML configs they have a few problems: - technical: missing comments are mentioned multiple times here so I will mention that while XML has comments they cannot be nested. - socially: for some reason (maybe because XML is structured enough that this doesn't immediately collapse?) XML tends to just grow and grow. People start programming in XML too, and not only using XSLT or other standard approaches but also in completely proprietary ways. At one project someone even wrote an authorization framework in Apache Tiles which allowed one to create roles using somewhere between 600 and 5000 lines of XML pr role. The benefit was of course that you could update the roles without touching the Java code. (In case it isn't immediately obvious: it would have been extremely much simpler to edit it in Java, and people who know enough Java to fix it are available at the right price, the XML system had to be learned at work.) Personally I just want it to be kept simple: - a settings.local.ini and default settings in settings.ini or something to that effect - if necessary, just use a code file: config.ts works just as well, or config.js if it needs to be adjustable at runtime without transpilation.