The NeXT/Apple ASCII encoding of their PLIST format is very similar to JSON and has been around forever. IIRC TextMate 1 made use of it for much of its bundle system.
Apple definitely had their anointed interchange format, and it was not JSON, for several reasons -- first among them that Plists predate JavaScript! -- but also because JavaScript types get a bit ambiguous in a ObjC/Cocoa context.
Interestingly, Plists can now be XML or JSON (or binary).
Old style text plists are still supported:
$ cat > /tmp/test.plist
{
"david" = "great";
"array" = ( 1,2,3,4 );
}
$ plutil -convert xml1 /tmp/test.plist -o -
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>array</key>
<array>
<string>1</string>
<string>2</string>
<string>3</string>
<string>4</string>
</array>
<key>david</key>
<string>great</string>
</dict>
</plist>
$ sw_vers -productVersion
10.10.1Less 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.
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)))
(dict (david great) (array ([int]1 [int]2 [int]3 [int]4)))
(dict (david great) (array ([bin-int]|AQ==| [bin-int]|Ag==| [bin-int]|AW==| [bin-int]|BA==|)))
Not nearly as insane as whoever came up with that XML abomination, though.
As long as it works, unless we categorize programmers debugging XML issues as non-human drones.
True. Read-only, however. :)
And the type ambiguity is amply demonstrated.
Nope! :-) While it's true that plutil doesn't support the format, open the plist in Xcode and edit it and it will save it out in the same old-school format. Editing through the programmatic API will also keep the format.
I will now manipulate ancient Plists with less fear. :-)