I've seen XML parsers that will convert element content from strings to native types by default.
-
I've seen XML parsers that will convert element content from strings to native types by default. So "0" becomes an int, "true" becomes a boolean, and "null" becomes an actual null. I had to take extra steps to keep everything as a string unless explicitly told not to.
JSON does not have this problem, BTW.
-
System shared this topic on
-
I've seen XML parsers that will convert element content from strings to native types by default. So "0" becomes an int, "true" becomes a boolean, and "null" becomes an actual null. I had to take extra steps to keep everything as a string unless explicitly told not to.
JSON does not have this problem, BTW.
I don't think anyone actually chooses XML. There's no reason to use it over JSON unless you need to.
-
I don't think anyone actually chooses XML. There's no reason to use it over JSON unless you need to.
The entirety of the banking world uses XML very heavily, as it's part of the SWIFT standards.
-
The entirety of the banking world uses XML very heavily, as it's part of the SWIFT standards.
I didn't say that it's not used. I say that you shouldn't if you have the option.
If the entire X world uses Y technology. You have no choice other than using Y technology.
-
I don't think anyone actually chooses XML. There's no reason to use it over JSON unless you need to.
Really? Right in front of my AJAX?
-
I don't think anyone actually chooses XML. There's no reason to use it over JSON unless you need to.
json is fine as a serialization format for things that need to be text, but it's not great as something that gets edited by hand.
not that I enjoy xml, but writing long strings in json is even worse. xml I can write multiline strings as a first class entity.
I can add a comment to an xml document, json i have to write something hacky like
"//": "my comment"and hope whatever is consuming it doesn't care.there's just as many problems with json parsers, since most but not all of them treat numbers as js numbers, which are basically floats. you can't rely on an arbitrary consumer having support to parse ints above a certain size so you just have to make everything a string and hope.
json allows duplicate keys, but they get overridden by the last occurrence. you can't round trip json without losing something. you can't rely on just seeing a key value in json text and that being correct since there could be another later. doesn't come up often but it's there.
-
I don't think anyone actually chooses XML. There's no reason to use it over JSON unless you need to.
XML can validate itself and there's the self-documenting WSDL; so while it has more overhead and an ugly syntax it can make for a more stable and earlier to understand API for your API's consumers.
-
XML can validate itself and there's the self-documenting WSDL; so while it has more overhead and an ugly syntax it can make for a more stable and earlier to understand API for your API's consumers.
This point is always stated about XML as if it were the most important part of choosing XML.
But jsonschema exists. It has the same capability.
-
This point is always stated about XML as if it were the most important part of choosing XML.
But jsonschema exists. It has the same capability.
Ah but... Nobody uses that!
Because then you wouldn't choose JSON -
System shared this topic on
