3 ms·

Hmm no, XML is 10x harder to read than JSON, period. It's just a ugly format with so much metadata information which are not human friendly. I think that's the

by Thaxll 6y ago

Hmm no, XML is 10x harder to read than JSON, period. It's just a ugly format with so much metadata information which are not human friendly. I think that's the main problem of XML it's not meant to be read by humans but people thought it was.

jandrese 6y ago
The primary problem with XML is that it's a document markup language being used to do data serialization. Schemas were bolted on after the fact to add enough metadata for data serialization, but that's a whole lot of added complexity on top of the already complex process of parsing a lightly specced document. So you have an already complex document parser (which you are using only a fraction of the full functionality!) with the added complexity of a schema system layered on top. This is why JSON took off so fast, it ditched the whole document part and just gave you the data.
mikece 6y ago
There's a huge difference between an XML document type designed by committee and something utilitarian used by an app developer. For example: <items> <item id="1" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="2" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="3" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="4" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="5" attr1="value 1" attr2="value 2" attr3="value 3" /> </item> It's not something that an IBM committee would have come up with but it fits the needs of an application. If XML has an "intrinsic fault" it's related to DTDs and namespaces which allow for the creation of horrible, complex monstrosities. XML can be every bit as stripped down and to-the-point as JSON, trading the curley braces for angle brackets. JSON's best point is that it doesn't support any of this needless complexity but it's still easy enough, with enough nested objects and arrays, to make something that's effectively not readable by a human.
- dragontamer 6y ago
 > It's not something that an IBM committee would have come up with but it fits the needs of an application. Items can be order-dependent in XML. So the "id=1" thing is still superfluous. See xs:sequence. (In contrast: xs:all declares something to be order independent). If you were doing XML for your own apps, I think xs:sequence items simplify parsing grossly. Ex: if you have Address, maybe you always want "Street", then "Zip Code", then "State". <Address> <Street> 1234 Blah Street </Street> <City> Springfield </City> <State> Whatever </State> <Zip> 55555 </Zip> </Address> By declaring that Street -> City -> State -> Zip must happen in that particular order, you can grossly simplify the parser's job when reading such data in. (Or writing it out). -------- If there are multiple People at this address, you could (and probably should) just list them out in order. <Address> <Street> 1234 Blah Street </Street> <City> Springfield </City> <State> Whatever </State> <Zip> 55555 </Zip> <People> Marge Homer Lisa Bart Maggie </People> </Address>
- GoblinSlayer 6y ago
 JSON does support namespaces (and comments) you just roll them by hand (ad hoc).

by Thaxll 6y ago

jandrese 6y ago

The primary problem with XML is that it's a document markup language being used to do data serialization. Schemas were bolted on after the fact to add enough metadata for data serialization, but that's a whole lot of added complexity on top of the already complex process of parsing a lightly specced document. So you have an already complex document parser (which you are using only a fraction of the full functionality!) with the added complexity of a schema system layered on top. This is why JSON took off so fast, it ditched the whole document part and just gave you the data.

mikece 6y ago

There's a huge difference between an XML document type designed by committee and something utilitarian used by an app developer. For example: <items> <item id="1" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="2" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="3" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="4" attr1="value 1" attr2="value 2" attr3="value 3" /> <item id="5" attr1="value 1" attr2="value 2" attr3="value 3" /> </item> It's not something that an IBM committee would have come up with but it fits the needs of an application. If XML has an "intrinsic fault" it's related to DTDs and namespaces which allow for the creation of horrible, complex monstrosities. XML can be every bit as stripped down and to-the-point as JSON, trading the curley braces for angle brackets. JSON's best point is that it doesn't support any of this needless complexity but it's still easy enough, with enough nested objects and arrays, to make something that's effectively not readable by a human.

dragontamer 6y ago
> It's not something that an IBM committee would have come up with but it fits the needs of an application. Items can be order-dependent in XML. So the "id=1" thing is still superfluous. See xs:sequence. (In contrast: xs:all declares something to be order independent). If you were doing XML for your own apps, I think xs:sequence items simplify parsing grossly. Ex: if you have Address, maybe you always want "Street", then "Zip Code", then "State". <Address> <Street> 1234 Blah Street </Street> <City> Springfield </City> <State> Whatever </State> <Zip> 55555 </Zip> </Address> By declaring that Street -> City -> State -> Zip must happen in that particular order, you can grossly simplify the parser's job when reading such data in. (Or writing it out). -------- If there are multiple People at this address, you could (and probably should) just list them out in order. <Address> <Street> 1234 Blah Street </Street> <City> Springfield </City> <State> Whatever </State> <Zip> 55555 </Zip> <People> Marge Homer Lisa Bart Maggie </People> </Address>
GoblinSlayer 6y ago
JSON does support namespaces (and comments) you just roll them by hand (ad hoc).