4 ms·

One reason in favor of using JSON over XML for web services I don't see mentioned often is that many XML schema based deserializers will by default fail if they

One reason in favor of using JSON over XML for web services I don't see mentioned often is that many XML schema based deserializers will by default fail if they get an unexpected element whereas JSON deserializers will ignore it, making it easier to remain backwards-compatible. Example: If you have the following defined in your .xsd <complexType name="MyMethodResponse"> <sequence> <element name="A" type="string" /> <element name="B" type="string" /> </sequence> </complexType> and you later add a "C", existing clients will fail, so you will have to create a new method along side the old one to remain compatible.

willcipriano 6y ago
I've always wondered why the people who designed these things thought that I wanted a exception to be thrown in that case. It seems to be a "enterprise" feature, Java SQL libraries often blow up if they find a column that isn't predefined.
rahilb 6y ago
JSON was clearly built with XGH axioms in mind: ‘errors only appear when you notice them’.
elcritch 6y ago
Following proper XML spec always led to more problems than what they were meant to solve. Sometimes I use XML, but just the syntax with a more html5 style to it. Similar to defaulting to error-ing on extra tags, I never got the point of making everything an element and adding extra redundant attributes. That's really just the result of XML that's automatically generated. Like the `<element... type="string">` in your example of classic XML, why not just use `<a>3</a>` or `<a int="3"/>`. XML proper styles still suggest the classic long/autogenerated form. Writing XML in html5 style like `<my-a data-value="3" />` makes it much friendlier. Or as I tend to use it for various internal protocols to wrap multiple CSV data in a file: <some-data type"csv" columns="A, B, C"> 1.3, 3.4, 5.6 1.3, 3.4, 5.6 </some-data> Technically That's really just html5 in a file I guess. :-) But html parsers also don't tend to complain about extra tags too.

willcipriano 6y ago

I've always wondered why the people who designed these things thought that I wanted a exception to be thrown in that case. It seems to be a "enterprise" feature, Java SQL libraries often blow up if they find a column that isn't predefined.

rahilb 6y ago

JSON was clearly built with XGH axioms in mind: ‘errors only appear when you notice them’.

elcritch 6y ago

Following proper XML spec always led to more problems than what they were meant to solve. Sometimes I use XML, but just the syntax with a more html5 style to it. Similar to defaulting to error-ing on extra tags, I never got the point of making everything an element and adding extra redundant attributes. That's really just the result of XML that's automatically generated. Like the `<element... type="string">` in your example of classic XML, why not just use `<a>3</a>` or `<a int="3"/>`. XML proper styles still suggest the classic long/autogenerated form. Writing XML in html5 style like `<my-a data-value="3" />` makes it much friendlier. Or as I tend to use it for various internal protocols to wrap multiple CSV data in a file: <some-data type"csv" columns="A, B, C"> 1.3, 3.4, 5.6 1.3, 3.4, 5.6 </some-data> Technically That's really just html5 in a file I guess. :-) But html parsers also don't tend to complain about extra tags too.