8 ms·

Why would anyone choose to use XML over JSON, other than for RSS?

theOnliest 10y ago
If you're actually marking up text, JSON doesn't really work. XML works alright for its intended use as a language. (That doesn't mean I hate it any less.)
- flogic 10y ago
  I think if you're marking up text, you really want to be using markdown one of the other wiki like formats. For writing you're much more likely to run into non-technical people who will be severely impacted by syntax errors.
vbezhenar 10y ago
I can parse/print XML (using either in memory parser or streaming parser), use XML Schema to validate XML, XPath expressions to select necessary parts, automatic object mapping, and that's all with standard library without a single external dependency in Java. I don't know why would I use JSON over XML, unless I have very good reasons to do so. For me the only thing that JSON got better is that JSON is directly mapped to commonly used data structures: arrays and maps.
- deleted 10y ago
  [deleted]
- moron4hire 10y ago
  > For me the only thing that JSON got better is that JSON is directly mapped to commonly used data structures: arrays and maps. This is nice, but it's also kind of a pain, as it makes you have to stop and think about which structured data elements it's capable of supporting and which you have to send your own metadata through the wire and then reconstruct on your own. For example: Dates. Which is a shame. If there is one data element I want the most help with serializing/deserializing, it's freaking Dates. All the other ones are super easy in comparison. There's just way to much subjective, dirty, human culture tied up in Dates. The only thing that I think is objectively better in all cases about JSON over XML is the less verbose end-structure syntax. I think XML only has Attributes because Tags have this silly need to state their name both as they enter and exit the room. <Tag1 attr1="hello" attr2="world"> <Tag2>how</Tag2> <Tag2>are</Tag2> <Tag2>you?</Tag2> </Tag1> For simple, unnestable data elements, having the more efficient Attribute starts to look attractive. If XML were more the form: <Tag1 attr1="hello" attr2="world"> <Tag2>how</> <Tag2>are</> <Tag2>you?</> </> It's actually only one more additional, required character to add than if the attribute value were specified as an element instead. <Tag1> <attr1>hello</> <attr2>world</> <Tag2>how</> <Tag2>are</> <Tag2>you?</> </> Heck, why stop there? Do we really need to have quite all of those angle brackets now? How about we just get rid of all the ones we can assume: <Tag1 <attr1 hello> <attr2 world> <Tag2 how> <Tag2 are> <Tag2 you?> > And finally, who even likes angle brackets? I've never enjoyed the dual duty they play as delimiters in XML and operators in other languages. Let's use a common set delimiter, something like square brackets or maybe parentheses. (Tag1 (attr1 hello) (attr2 world) (Tag2 how) (Tag2 are) (Tag2 you?)) Now where have I seen this before? PS: JSON that is as nearly as equivalent as I can make it is not much less verbose than original XML, and requires some level of convention to make up for the differences: {Tag1: { attr1: "hello", attr2: "world", children: [ {Tag2: "how"}, {Tag2: "are"}, {Tag2: "you?}]} Though I'm sure in common practice it'd have a lot of the original metadata of the XML version thrown away: {attr1: "hello", attr2: "world", children: [ "how", "are", "you?"]}
  - deleted 10y ago
    [deleted]
  - mbrock 10y ago
    The XML tag style is much, much easier to work with when you're dealing with markup. And XML's purpose is to be an Extensible Markup Language. It's way more appropriate than JSON or S-expressions for that. (Do you prefer to write HTML documents as S-expressions?)
    - kccqzy 10y ago
      Yes. With good tooling (such as Emacs), markup is much more pleasant to write in S-expressions than XML.
    - wtbob 10y ago
      > Do you prefer to write HTML documents as S-expressions? Actually, yes. I use CL-WHO[1] a lot, in which one can write: (:html (:head (:title "Foo bar") (:link :rel "stylesheet" :href="baz.css")) (:body (:p "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum ullamcorper efficitur purus, at suscipit nunc luctus vitae.") (:ol (:li "Cras vel est accumsan, malesuada leo eu, iaculis nulla.") (:li "Proin nec mi feugiat, posuere enim in, vehicula erat.") (:li "Morbi vitae purus nec neque posuere pharetra ultricies in nibh.") (:li "Nam maximus lectus faucibus, ullamcorper lectus aliquam, aliquam lectus.")))) Which I contend is prettier than the equivalent HTML. [1] http://weitz.de/cl-who/ http://weitz.de/cl-who/
      - mbrock 10y ago
        I like S-expressions too, especially when generating markup programmatically. For hand-writing HTML/XML documents, which I do quite a lot, I really enjoy the tag style because of the verbose end tags and the ease of moving blocks. It's at least nice enough to make me annoyed when people claim the tag syntax is some horrible stupid disaster compared to S-expressions or (worse) JSON.
        10y ago
cptskippy 10y ago
For one, JSON didn't exist 15 years ago. For another, JSON didn't have validation or schemas 5 years ago.
- einhverfr 10y ago
  Even there, the schemas and validation are very lightweight compared to what XML can do. As I usually say, JSON is for relatively free-form, dynamically typed languages, but if one side is uses a statically typed language, XML is probably the better choice.
  - cptskippy 10y ago
    Hmm... I always tend to use XML for B2B communication or Mine-to-Theirs type RPCs. I use JSON primarily for Client-to-Server communication internally with own applications or for public APIs.
- deleted 10y ago
  [deleted]
- beagle3 10y ago
  JSON was defined in April 2001, basically a subset of JavaScript specs from 1999. So, JSON did exist 15 years ago, but not 16 years ago, although you have to go back 20 years if you want your statement to not just be about the name. And yet ... how many of the decisions to use XML go back those 15 years? Hardly any.
  - cptskippy 10y ago
    JSON may have been created 15 years ago but it wasn't well known or commonly used for a number of years. Yahoo! only started using it in 2005 and Google in 2006. XML had been around and in use for years prior to that and even today has a much richer toolchain.
jasonkostempski 10y ago
Because its prefered or reqired by a well paying customer. With any sane web framework you get both JSON and XML out of the box. If the well paying customer doesnt send an XML Accept header you make it the default respose type and tell everyone else to send a JSON Accept header. If theres a conflict between multiple well paying customers, you make new end points.
edejong 10y ago
I'll add some more reasons to the flamebait: - JSON doesn't have namespaces, making integration of different data-sources quite hard. - XML allows me to do versioning within documents. - An extremely large corpus of well-tested libraries are available. - As opposed to JSON, XML and accompanying standards (XSLT, XML Schema, XPath, XQuery) are extremely well documented. - XML validation, parsing and processing can happen at the same time, allowing streaming solutions. Using the XML schema, a parser can be created which is optimized for a specific stream of data. (edit: formatting)
- qwertyuiop924 10y ago
  All right, I'll bite: >JSON doesn't have namespaces, making integration of different data-sources quite hard. Yeah, and how often do you merge two data formats like that into one data format in a way that doesn't require massive transformations anyway? >XML allows me to do versioning within documents Well, that's fantastic. Because XML is designed for DOCUMENTS. But JSON is designed as a wire protocol, and a data exchange format, which is very different. You shouldn't use JSON for documents, and I very much doubt that's what OP was talking about. >An extremely large corpus of well-tested libraries are available. For your language. But XML is fairly complex, and there are a lot of environments with no support, and JSON parsing is so simple and easy that the complete grammar, as well as the semantics, are on the front page of the website, and it's unlikely your language doesn't have support for it already. >As opposed to JSON, XML and accompanying standards (XSLT, XML Schema, XPath, XQuery) are extremely well documented. The grammar and semantics are on the front page of the site. And JSON is simple enough there's little more to it than that. >XML validation, parsing and processing can happen at the same time, allowing streaming solutions. Using the XML schema, a parser can be created which is optimized for a specific stream of data. Really? That's actually kinda cool. :-)
  - edejong 10y ago
    Alright, in the flamebait fashion, I'll bite back :) > Yeah, and how often do you merge two data formats like that into one data format in a way that doesn't require massive transformations anyway? Actually, quite a lot in the past! Back in 2009 I did some XProc pipelining of messages. These pipelines were a bit like reactive streams, which were (mostly) agnostic of the contents. This allowed me to combine, dissect and route streams of data in an intuitive way. Maybe you can compare it with mapping over a collection: you don't care what's inside, but you want to preserve the contents. XProc was kind of a functional programming + reactive approach to data processing. Pretty cool and ahead of its time, if you ask me. > But JSON is designed as a wire protocol Reference, please? Even if I subscribe to one definition of 'wire protocol' on the internet (there are many), I don't think it creates a meaningful distinction between XML and JSON. > JSON parsing is so simple Actually, it is, and it isn't. Yes, there are very few primitives (strings, booleans, numbers, arrays, objects), but this also causes important limitations. For example, it is rather cumbersome and unspecified to transfer binary data in a JSON document (base64 encoding). Another thing: how easy is it to parse a streaming JSON document in Javascript? > The grammar and semantics are on the front page of the site. Admittedly, that's a lot easier than, say: https://www.w3.org/TR/xml11/ https://www.w3.org/TR/xml11/ These guys really took it too far... > That's actually kinda cool. That's what I thought too when I first heard about it :)
rwmj 10y ago
XPath expressions are actually pretty cool (and I say this as not a great fan of XML in general). The ability to search and select elements is something we use all the time. For many examples, search for "xpath_" in https://github.com/libguestfs/libguestfs/blob/master/v2v/input_libvirtxml.ml#L52 https://github.com/libguestfs/libguestfs/blob/master/v2v/inp...
- glippiglop 10y ago
  I'd drink to that, XPath is incredibly useful and easily mastered. I'm also fond of XSD and XSLT myself. They can be obtuse at times, but have been indispensable in the use cases that I've needed them for.
AndrewDucker 10y ago
Working in a statically typed language, and using schemas to ensure that the generated messages are correct, because we can generated classes that map onto the required data structures. So far as I know JSON doesn't allow for that.
einhverfr 10y ago
If you are working with statically typed languages, the validation of XML is far superior to anything you can do over json, unless you want to write your own formats for defining data structures in JSON. JSON, remember, was written for a language without even firm object structures. It is great in that environment but all exchange formats require external knowledge to validate, and XML unlike the others provides a way to do that.
mhomde 10y ago
JSON is nice for structured data but when it comes to more mixed document style data XML is preferable IMO
jameshart 10y ago
Most of the advice applies equally to generating JSON data as well.

If you're actually marking up text, JSON doesn't really work. XML works alright for its intended use as a language. (That doesn't mean I hate it any less.)

flogic 10y ago
I think if you're marking up text, you really want to be using markdown one of the other wiki like formats. For writing you're much more likely to run into non-technical people who will be severely impacted by syntax errors.

vbezhenar 10y ago

I can parse/print XML (using either in memory parser or streaming parser), use XML Schema to validate XML, XPath expressions to select necessary parts, automatic object mapping, and that's all with standard library without a single external dependency in Java. I don't know why would I use JSON over XML, unless I have very good reasons to do so. For me the only thing that JSON got better is that JSON is directly mapped to commonly used data structures: arrays and maps.

deleted 10y ago
[deleted]
moron4hire 10y ago
> For me the only thing that JSON got better is that JSON is directly mapped to commonly used data structures: arrays and maps. This is nice, but it's also kind of a pain, as it makes you have to stop and think about which structured data elements it's capable of supporting and which you have to send your own metadata through the wire and then reconstruct on your own. For example: Dates. Which is a shame. If there is one data element I want the most help with serializing/deserializing, it's freaking Dates. All the other ones are super easy in comparison. There's just way to much subjective, dirty, human culture tied up in Dates. The only thing that I think is objectively better in all cases about JSON over XML is the less verbose end-structure syntax. I think XML only has Attributes because Tags have this silly need to state their name both as they enter and exit the room. <Tag1 attr1="hello" attr2="world"> <Tag2>how</Tag2> <Tag2>are</Tag2> <Tag2>you?</Tag2> </Tag1> For simple, unnestable data elements, having the more efficient Attribute starts to look attractive. If XML were more the form: <Tag1 attr1="hello" attr2="world"> <Tag2>how</> <Tag2>are</> <Tag2>you?</> </> It's actually only one more additional, required character to add than if the attribute value were specified as an element instead. <Tag1> <attr1>hello</> <attr2>world</> <Tag2>how</> <Tag2>are</> <Tag2>you?</> </> Heck, why stop there? Do we really need to have quite all of those angle brackets now? How about we just get rid of all the ones we can assume: <Tag1 <attr1 hello> <attr2 world> <Tag2 how> <Tag2 are> <Tag2 you?> > And finally, who even likes angle brackets? I've never enjoyed the dual duty they play as delimiters in XML and operators in other languages. Let's use a common set delimiter, something like square brackets or maybe parentheses. (Tag1 (attr1 hello) (attr2 world) (Tag2 how) (Tag2 are) (Tag2 you?)) Now where have I seen this before? PS: JSON that is as nearly as equivalent as I can make it is not much less verbose than original XML, and requires some level of convention to make up for the differences: {Tag1: { attr1: "hello", attr2: "world", children: [ {Tag2: "how"}, {Tag2: "are"}, {Tag2: "you?}]} Though I'm sure in common practice it'd have a lot of the original metadata of the XML version thrown away: {attr1: "hello", attr2: "world", children: [ "how", "are", "you?"]}
- deleted 10y ago
  [deleted]
- mbrock 10y ago
  The XML tag style is much, much easier to work with when you're dealing with markup. And XML's purpose is to be an Extensible Markup Language. It's way more appropriate than JSON or S-expressions for that. (Do you prefer to write HTML documents as S-expressions?)
  - kccqzy 10y ago
    Yes. With good tooling (such as Emacs), markup is much more pleasant to write in S-expressions than XML.
  - wtbob 10y ago
    > Do you prefer to write HTML documents as S-expressions? Actually, yes. I use CL-WHO[1] a lot, in which one can write: (:html (:head (:title "Foo bar") (:link :rel "stylesheet" :href="baz.css")) (:body (:p "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum ullamcorper efficitur purus, at suscipit nunc luctus vitae.") (:ol (:li "Cras vel est accumsan, malesuada leo eu, iaculis nulla.") (:li "Proin nec mi feugiat, posuere enim in, vehicula erat.") (:li "Morbi vitae purus nec neque posuere pharetra ultricies in nibh.") (:li "Nam maximus lectus faucibus, ullamcorper lectus aliquam, aliquam lectus.")))) Which I contend is prettier than the equivalent HTML. [1] http://weitz.de/cl-who/ http://weitz.de/cl-who/
    - mbrock 10y ago
      I like S-expressions too, especially when generating markup programmatically. For hand-writing HTML/XML documents, which I do quite a lot, I really enjoy the tag style because of the verbose end tags and the ease of moving blocks. It's at least nice enough to make me annoyed when people claim the tag syntax is some horrible stupid disaster compared to S-expressions or (worse) JSON.
      - 10y ago

cptskippy 10y ago

For one, JSON didn't exist 15 years ago. For another, JSON didn't have validation or schemas 5 years ago.

einhverfr 10y ago
Even there, the schemas and validation are very lightweight compared to what XML can do. As I usually say, JSON is for relatively free-form, dynamically typed languages, but if one side is uses a statically typed language, XML is probably the better choice.
- cptskippy 10y ago
  Hmm... I always tend to use XML for B2B communication or Mine-to-Theirs type RPCs. I use JSON primarily for Client-to-Server communication internally with own applications or for public APIs.
deleted 10y ago
[deleted]
beagle3 10y ago
JSON was defined in April 2001, basically a subset of JavaScript specs from 1999. So, JSON did exist 15 years ago, but not 16 years ago, although you have to go back 20 years if you want your statement to not just be about the name. And yet ... how many of the decisions to use XML go back those 15 years? Hardly any.
- cptskippy 10y ago
  JSON may have been created 15 years ago but it wasn't well known or commonly used for a number of years. Yahoo! only started using it in 2005 and Google in 2006. XML had been around and in use for years prior to that and even today has a much richer toolchain.

jasonkostempski 10y ago

Because its prefered or reqired by a well paying customer. With any sane web framework you get both JSON and XML out of the box. If the well paying customer doesnt send an XML Accept header you make it the default respose type and tell everyone else to send a JSON Accept header. If theres a conflict between multiple well paying customers, you make new end points.

edejong 10y ago

I'll add some more reasons to the flamebait: - JSON doesn't have namespaces, making integration of different data-sources quite hard. - XML allows me to do versioning within documents. - An extremely large corpus of well-tested libraries are available. - As opposed to JSON, XML and accompanying standards (XSLT, XML Schema, XPath, XQuery) are extremely well documented. - XML validation, parsing and processing can happen at the same time, allowing streaming solutions. Using the XML schema, a parser can be created which is optimized for a specific stream of data. (edit: formatting)

qwertyuiop924 10y ago
All right, I'll bite: >JSON doesn't have namespaces, making integration of different data-sources quite hard. Yeah, and how often do you merge two data formats like that into one data format in a way that doesn't require massive transformations anyway? >XML allows me to do versioning within documents Well, that's fantastic. Because XML is designed for DOCUMENTS. But JSON is designed as a wire protocol, and a data exchange format, which is very different. You shouldn't use JSON for documents, and I very much doubt that's what OP was talking about. >An extremely large corpus of well-tested libraries are available. For your language. But XML is fairly complex, and there are a lot of environments with no support, and JSON parsing is so simple and easy that the complete grammar, as well as the semantics, are on the front page of the website, and it's unlikely your language doesn't have support for it already. >As opposed to JSON, XML and accompanying standards (XSLT, XML Schema, XPath, XQuery) are extremely well documented. The grammar and semantics are on the front page of the site. And JSON is simple enough there's little more to it than that. >XML validation, parsing and processing can happen at the same time, allowing streaming solutions. Using the XML schema, a parser can be created which is optimized for a specific stream of data. Really? That's actually kinda cool. :-)
- edejong 10y ago
  Alright, in the flamebait fashion, I'll bite back :) > Yeah, and how often do you merge two data formats like that into one data format in a way that doesn't require massive transformations anyway? Actually, quite a lot in the past! Back in 2009 I did some XProc pipelining of messages. These pipelines were a bit like reactive streams, which were (mostly) agnostic of the contents. This allowed me to combine, dissect and route streams of data in an intuitive way. Maybe you can compare it with mapping over a collection: you don't care what's inside, but you want to preserve the contents. XProc was kind of a functional programming + reactive approach to data processing. Pretty cool and ahead of its time, if you ask me. > But JSON is designed as a wire protocol Reference, please? Even if I subscribe to one definition of 'wire protocol' on the internet (there are many), I don't think it creates a meaningful distinction between XML and JSON. > JSON parsing is so simple Actually, it is, and it isn't. Yes, there are very few primitives (strings, booleans, numbers, arrays, objects), but this also causes important limitations. For example, it is rather cumbersome and unspecified to transfer binary data in a JSON document (base64 encoding). Another thing: how easy is it to parse a streaming JSON document in Javascript? > The grammar and semantics are on the front page of the site. Admittedly, that's a lot easier than, say: https://www.w3.org/TR/xml11/ https://www.w3.org/TR/xml11/ These guys really took it too far... > That's actually kinda cool. That's what I thought too when I first heard about it :)

rwmj 10y ago

XPath expressions are actually pretty cool (and I say this as not a great fan of XML in general). The ability to search and select elements is something we use all the time. For many examples, search for "xpath_" in https://github.com/libguestfs/libguestfs/blob/master/v2v/input_libvirtxml.ml#L52 https://github.com/libguestfs/libguestfs/blob/master/v2v/inp...

glippiglop 10y ago
I'd drink to that, XPath is incredibly useful and easily mastered. I'm also fond of XSD and XSLT myself. They can be obtuse at times, but have been indispensable in the use cases that I've needed them for.

AndrewDucker 10y ago

Working in a statically typed language, and using schemas to ensure that the generated messages are correct, because we can generated classes that map onto the required data structures. So far as I know JSON doesn't allow for that.

einhverfr 10y ago

If you are working with statically typed languages, the validation of XML is far superior to anything you can do over json, unless you want to write your own formats for defining data structures in JSON. JSON, remember, was written for a language without even firm object structures. It is great in that environment but all exchange formats require external knowledge to validate, and XML unlike the others provides a way to do that.

mhomde 10y ago

JSON is nice for structured data but when it comes to more mixed document style data XML is preferable IMO

jameshart 10y ago

Most of the advice applies equally to generating JSON data as well.