32 ms·

Why did xml lose to yaml/json?

kjsingh 5y ago
more verbose? start and closing tags?
fulafel 5y ago
It was designed for documents and text with predifined structure. JSON os just a bag of stuff and there is no grand json standard body to develop common schema systems and other complex and rarely well fitting pile-on layers that devs would be pressured to use
qsort 5y ago
You can only reinvent S-expressions so many times... Honestly I never understood how XML became popular in the first place. The problem it tries to solve is not very hard, and it doesn't solve that problem very well.
- gugagore 5y ago
  One of the problems that XML aims to solve is that you can get two XML documents and combine elements of them into a third one, maintaining the right semantics, even if each of the documents use the `<foo>` tag to mean different things. It accomplishes this with namespacing. In my experience, it's a headache to handle namespaces in XML, e.g. when trying to refer to tag names in an XPath query. That is one example of how XML goes beyond S-expressions. I still don't think it's a particularly hard problem.
  - qsort 5y ago
    There's no reason why any of that couldn't be replicated with JSON, YAML or even with S-expressions. To play the devil's advocate, one of the nice features of XML is schemas. The reason why complex formats with validation etc. don't really work out is that they are most often used for data in transit as opposed to data at rest. The correct format for typed data at rest that conforms to a schema is a SQL database and that won't change any time soon. If you're working with data in transit, schemas, validation etc. are more trouble than they're worth.
    - regularfry 5y ago
      There's no reason why it couldn't be replicated, but it isn't - at least, not in any way with broad traction. It's not useful to compare something that could exist but doesn't with something that not only exists but is universal in its ecosystem. That universality is a feature in itself.
- goto11 5y ago
  XML is great for its intended purpose - structured text with metadata. For other purposes like configuration files or rpc, the element/attribute distinction is superfluous and just lead to overly verbose syntax. Unfortunately the hype cycle is such that when a technology becomes fashionable it becomes used even in contexts where it is not appropriate. This in turn leads to a backlash against the overall technology, not just against inappropriate use of it.
  - TuringTest 5y ago
    XML is awful for structured text with metadata. Half of the time you don't know whether your object properties were -or should be- stored as element attributes, element children or a CDATA block when trying to access it programmatically. Defining a sane schema fit for all the places and use cases where it will be needed is an exercise in frustration. Lightweight markup won for structured text because it is simple to use, and you can expand it in a piecemeal fashion as needed. See Worse-is-better and the adoption of the C language for how this happens. This happens even for well-designed lightweight markup; everybody prefers Markdown over asciidoc because you only need to learn like 5 syntax elements to get it up and running, even if it forces you to to add by hand later all the functions that were already available in asciidoc.
    - goto11 5y ago
      Since you talk about objects with properties, I assume you are thinking about serializing an object graph to XML. I agree the element/attribute distinction and mixed content is not very useful in this context. JSON or similar is fine for such data. Structured text with metadata is something like this: <b>Hello, <a href="foo.org">world</a>!</b> The element/attribute distinction and mixed content is useful here. Btw. CData-blocks are purely an escape mechanism on the syntactic level. It should be completely transparent on the application level (e.g. like backslash escapes in a JSON string).
stickfigure 5y ago
Lose to yaml/json for what purpose? As an RPC protocol, JSON is lighter weight and maps more directly to programming structures. As a config file format, YAML is a bit terser. Especially since most configurations are just key/value pairs. Though there's a growing backlash against YAML so I wouldn't count on this lasting. As a document format... XML still wins? HTML is still (basically) XML. Lots of business data interchange is still XML. JSON is terrible as a document format, and YAML isn't even in the running.
- bayindirh 5y ago
  For structured data, I still find XML superior to other formats, especially if it's gonna live on the disk for a long time. I used XML as a input file format for a scientific application and I still can't see how I can store same data in a YAML file, with inherent verification capabilities and with some flexibility for reordering blocks. For smaller stuff, YAML is fine, for transient over the wire data exchange, JSON is fine, but for heavy lifting, XML is indispensable IME.
  - regularfry 5y ago
    What really annoys me is where you've got perfectly workable XML document standards getting replaced (or at least competed with for brain time) by JSON standards that are measurably worse. There's one document standard in particular which is designed for news articles, and in that case you want and need to be able to embed HTML representations in the outer document wrapper: this is a perfect fit for XML namespaces, it's almost exactly the use case they were intended for. But looking at the replacement JSON standard I find string fields called things like "body_html" or "body_text" and it just makes me _weep_.
    - bayindirh 5y ago
      From my understanding, JSON won over not because it's superior, but it's much easier to build and consume. To some degree, YAML seems to be liked because of the very same feature of Python: Scoping via indentation. However, I'm not sure about that. XML is akin to space shuttle. Complicated but, well thought out. Well designed for its mission, robust, but somewhat clunky. However, it's a much more accessible member of "software engineering for the enterprise" era. These features are not fit for today's "fast" software engineering. Who'll parse that XML, yet alone verify it? Who'll write the callbacks? Or is a DOM parser better? Today people "don't have time for that (TM)". On the more realistic side, XML is really useful and robust. Yes, it's not as fast to implement, but it's forgettable. Add a DTD verification step, then parse away. After ironing the kinks out, your parser can outlive Voyager probes, maybe even humanity itself. But it's overkill for most "move fast, break things" projects of today. I for one, will use XML for the foreseeable future for my projects. Won't whine for consuming JSON and writing hard to understand YAML files, but if I'm going to exchange big, important data and store it on disk, it'll be XML.
buro9 5y ago
> Why did xml lose to yaml/json? XML had gained complexity: schemas, namespaces, validation, translation, and then was extended to cover RPC behaviour via SOAP, WSDL, etc, with some annoyances and papercuts around escaping things and using CDATA. At a certain point the onboarding requirement for a new engineer who just wanted to exchange some data between two systems or write a config file was no longer "open a text file and write what you want" but "learn all of this tooling and perform this incantation". Then, when you factor in that JavaScript was becoming the default for everything on the web and JQuery had given the world a better interface to XmlHttpRequest... but that you had to then translate client-side the XML into JS objects... At this point convenience won. Just write the config file in JSON, send data as JSON over HTTP, have the browser just receive native JavaScript objects. Of course, time passes and now we're slowly adding in all of the complexity again as it turns out it's needed at a certain scale to be sure that systems work as intended. YAML emerged when managing JSON configs via build tools become troublesome (trailing commas within config files for arrays built via Puppet, etc). YAML solved that, and made it also a little easier to read (for some other compromises, like now being whitespace sensitive). Perhaps something else more convenient is just around the corner and we can do it all again. If you were to build a competitor to XML/JSON/YAML today... what would it look like?
- hyperpallium2 5y ago
  JSON is C-like Text formats will evolve to the point of being too complex to use. Those that can will be replaced by those that cannot.
hyperpallium2 5y ago
XML is a markup language, JSON is an object notation.

more verbose? start and closing tags?

It was designed for documents and text with predifined structure. JSON os just a bag of stuff and there is no grand json standard body to develop common schema systems and other complex and rarely well fitting pile-on layers that devs would be pressured to use

qsort 5y ago

You can only reinvent S-expressions so many times... Honestly I never understood how XML became popular in the first place. The problem it tries to solve is not very hard, and it doesn't solve that problem very well.

gugagore 5y ago
One of the problems that XML aims to solve is that you can get two XML documents and combine elements of them into a third one, maintaining the right semantics, even if each of the documents use the `<foo>` tag to mean different things. It accomplishes this with namespacing. In my experience, it's a headache to handle namespaces in XML, e.g. when trying to refer to tag names in an XPath query. That is one example of how XML goes beyond S-expressions. I still don't think it's a particularly hard problem.
- qsort 5y ago
  There's no reason why any of that couldn't be replicated with JSON, YAML or even with S-expressions. To play the devil's advocate, one of the nice features of XML is schemas. The reason why complex formats with validation etc. don't really work out is that they are most often used for data in transit as opposed to data at rest. The correct format for typed data at rest that conforms to a schema is a SQL database and that won't change any time soon. If you're working with data in transit, schemas, validation etc. are more trouble than they're worth.
  - regularfry 5y ago
    There's no reason why it couldn't be replicated, but it isn't - at least, not in any way with broad traction. It's not useful to compare something that could exist but doesn't with something that not only exists but is universal in its ecosystem. That universality is a feature in itself.
goto11 5y ago
XML is great for its intended purpose - structured text with metadata. For other purposes like configuration files or rpc, the element/attribute distinction is superfluous and just lead to overly verbose syntax. Unfortunately the hype cycle is such that when a technology becomes fashionable it becomes used even in contexts where it is not appropriate. This in turn leads to a backlash against the overall technology, not just against inappropriate use of it.
- TuringTest 5y ago
  XML is awful for structured text with metadata. Half of the time you don't know whether your object properties were -or should be- stored as element attributes, element children or a CDATA block when trying to access it programmatically. Defining a sane schema fit for all the places and use cases where it will be needed is an exercise in frustration. Lightweight markup won for structured text because it is simple to use, and you can expand it in a piecemeal fashion as needed. See Worse-is-better and the adoption of the C language for how this happens. This happens even for well-designed lightweight markup; everybody prefers Markdown over asciidoc because you only need to learn like 5 syntax elements to get it up and running, even if it forces you to to add by hand later all the functions that were already available in asciidoc.
  - goto11 5y ago
    Since you talk about objects with properties, I assume you are thinking about serializing an object graph to XML. I agree the element/attribute distinction and mixed content is not very useful in this context. JSON or similar is fine for such data. Structured text with metadata is something like this: <b>Hello, <a href="foo.org">world</a>!</b> The element/attribute distinction and mixed content is useful here. Btw. CData-blocks are purely an escape mechanism on the syntactic level. It should be completely transparent on the application level (e.g. like backslash escapes in a JSON string).

stickfigure 5y ago

Lose to yaml/json for what purpose? As an RPC protocol, JSON is lighter weight and maps more directly to programming structures. As a config file format, YAML is a bit terser. Especially since most configurations are just key/value pairs. Though there's a growing backlash against YAML so I wouldn't count on this lasting. As a document format... XML still wins? HTML is still (basically) XML. Lots of business data interchange is still XML. JSON is terrible as a document format, and YAML isn't even in the running.

bayindirh 5y ago
For structured data, I still find XML superior to other formats, especially if it's gonna live on the disk for a long time. I used XML as a input file format for a scientific application and I still can't see how I can store same data in a YAML file, with inherent verification capabilities and with some flexibility for reordering blocks. For smaller stuff, YAML is fine, for transient over the wire data exchange, JSON is fine, but for heavy lifting, XML is indispensable IME.
- regularfry 5y ago
  What really annoys me is where you've got perfectly workable XML document standards getting replaced (or at least competed with for brain time) by JSON standards that are measurably worse. There's one document standard in particular which is designed for news articles, and in that case you want and need to be able to embed HTML representations in the outer document wrapper: this is a perfect fit for XML namespaces, it's almost exactly the use case they were intended for. But looking at the replacement JSON standard I find string fields called things like "body_html" or "body_text" and it just makes me _weep_.
  - bayindirh 5y ago
    From my understanding, JSON won over not because it's superior, but it's much easier to build and consume. To some degree, YAML seems to be liked because of the very same feature of Python: Scoping via indentation. However, I'm not sure about that. XML is akin to space shuttle. Complicated but, well thought out. Well designed for its mission, robust, but somewhat clunky. However, it's a much more accessible member of "software engineering for the enterprise" era. These features are not fit for today's "fast" software engineering. Who'll parse that XML, yet alone verify it? Who'll write the callbacks? Or is a DOM parser better? Today people "don't have time for that (TM)". On the more realistic side, XML is really useful and robust. Yes, it's not as fast to implement, but it's forgettable. Add a DTD verification step, then parse away. After ironing the kinks out, your parser can outlive Voyager probes, maybe even humanity itself. But it's overkill for most "move fast, break things" projects of today. I for one, will use XML for the foreseeable future for my projects. Won't whine for consuming JSON and writing hard to understand YAML files, but if I'm going to exchange big, important data and store it on disk, it'll be XML.

buro9 5y ago

> Why did xml lose to yaml/json? XML had gained complexity: schemas, namespaces, validation, translation, and then was extended to cover RPC behaviour via SOAP, WSDL, etc, with some annoyances and papercuts around escaping things and using CDATA. At a certain point the onboarding requirement for a new engineer who just wanted to exchange some data between two systems or write a config file was no longer "open a text file and write what you want" but "learn all of this tooling and perform this incantation". Then, when you factor in that JavaScript was becoming the default for everything on the web and JQuery had given the world a better interface to XmlHttpRequest... but that you had to then translate client-side the XML into JS objects... At this point convenience won. Just write the config file in JSON, send data as JSON over HTTP, have the browser just receive native JavaScript objects. Of course, time passes and now we're slowly adding in all of the complexity again as it turns out it's needed at a certain scale to be sure that systems work as intended. YAML emerged when managing JSON configs via build tools become troublesome (trailing commas within config files for arrays built via Puppet, etc). YAML solved that, and made it also a little easier to read (for some other compromises, like now being whitespace sensitive). Perhaps something else more convenient is just around the corner and we can do it all again. If you were to build a competitor to XML/JSON/YAML today... what would it look like?

hyperpallium2 5y ago
JSON is C-like Text formats will evolve to the point of being too complex to use. Those that can will be replaced by those that cannot.

hyperpallium2 5y ago

XML is a markup language, JSON is an object notation.