Less glibly, humans never have to deal with it. Data is serialized and deserialized, typically in binary format. It exports to XML merely as a convenience.
And critically, XML can be typed properly for all ObjC/Cocoa types (sometimes with characteristic XML awkwardness). That XML is wrongly typed, due to the ambiguous source input. JSON would have similar problems. Correct beats pretty, in this case.
As long as it works, unless we categorize programmers debugging XML issues as non-human drones.
Well yeah, but an XML parser would also have no problem with '<tag name="p"><chardata><char>T</char><char>h</char><char>i</char><char>s</char><whitespace type="space" /><char>i</char><char>s</char><whitespace type="space" /><char>i</char><char>n</char><char>a</char><char>n</char><char>e</char><punctuation type="full-stop" display-char="." /></tag>', but that would be completely insane.
> Less glibly, humans never have to deal with it. […] It exports to XML merely as a convenience.
For…humans, no?
> And critically, XML can be typed
It looks like the plist supported types too, although I don't know for certain. At least, the numbers weren't quoted in the plist.
> JSON would have similar problems.
Would it? '"2" !== 2', IIRC.
Of course, my preferred syntax would be:
(dict (david great) (array (1 2 3 4)))
if one wanted to treat numbers as text and: (dict (david great) (array ([int]1 [int]2 [int]3 [int]4)))
if one wanted to indicate that they are ASCII decimal-encoded integers or: (dict (david great) (array ([bin-int]|AQ==| [bin-int]|Ag==| [bin-int]|AW==| [bin-int]|BA==|)))
if one wished to use binary encoding using network-transfer order, but I am clearly insane.Not nearly as insane as whoever came up with that XML abomination, though.