Talk:Property list

Mac OS bias (ignoring NeXT and GNU)

This article, before I got to it, had what I would call a "deep Mac OS bias". That is to say, it ignored NeXTSTEP, which is where plist files originated, and GNUstep, which also implements plists. I've tried to fix that, along with other factual inaccuracies. – Andyluciano 22:43, 23 December 2005 (UTC)[reply]

Move?

I think this page should be moved to something like Property List, property list, Property List file, or property list file. – Mipadi 16:52, 6 April 2006 (UTC)[reply]

Recent edit

Removed advertisement (which was factually incorrect to boot; said that a GUI tool was a command line tool). Imo, a list of plist editors apart from Apple's own does fit with the article, but in the External Links section or something, not where it was before my edit. --Devnevyn 15:05, 10 April 2007 (UTC)[reply]

MIME type?

Is there MIME type for plist? May I suggest application/vnd.apple.plist+xml —Preceding unsigned comment added by 82.70.200.181 (talk) 10:52, 9 June 2009 (UTC)[reply]

Nokia

OMG! The Nokia "Web Runtime" widget format uses a plist file! See: [1] and [2]
Of course Nokia defines their "own" DTD, but the file looks just like a Mac OS X plist. Maybe this has to do with the browser being based on Webkit? Nice influence however.. >;-)
--81.10.136.83 (talk) 18:05, 22 March 2010 (UTC)[reply]

Dead Applescript feature link....

http://www.apple.com/applescript/features/propertylists.html is improperly used in the article, and the link is dead; it redirects to something generic now. I suppose I could replace it with http://web.archive.org/web/20090424003555/http://www.apple.com/applescript/features/propertylists.html but .... well, I'll do that, and convert to a reference...--Elvey (talk) 00:51, 5 October 2012 (UTC)[reply]

Naming Convention

Can someone add a section about the naming convention of plists? It's the information I was looking for on this page and didn't see it. (Specifically, I was trying to figure out why all the plists start with com or org before resolving to the application). — Preceding unsigned comment added by 76.91.29.182 (talk) 22:51, 24 January 2013 (UTC)[reply]

Many Issues

This page is still biased toward OSX.
As such the page talks about property list files, specifically OSX implementation of such files.
Property lists are also a type of Associative array, which is a Data type.
There is no mention of Lisp which has used plists since it's inception ^[1], or at least since 1990. ^[2]

This page should be named "Property List (File)" and another page similar to Hash Table should be created, or This page should keep the name, but become about Property Lists in general (Data Type, File Type, Applications in Systems, Applications in Computer Science or Programming).

173.15.164.249 (talk) 19:00, 10 February 2016 (UTC) Elijah Beale[reply]

References

        Yes, I agree, especially with the OSX bias. DoggieTimesTwo (talk) 22:48, 22 May 2020 (UTC)[reply]

Too short of a "See Also"

The See Also section seems too short for a big heading. Maybe merging it to another section or making it smaller? DoggieTimesTwo (talk) 22:48, 22 May 2020 (UTC)[reply]

Lacking citations about NSSerializer

The article says "(The Cocoa NSSerializer from before Mac OS X 10.2 emits old-styled output.)", but it does not provide a source, and I have some reason to doubt it is true.

I did some digging – none of it is conclusive evidence in either direction. But perhaps it's interesting, or will help find a more conclusive source:

NSSerializer and NSDeserializer are still shipped with the Foundation framework under macOS 15 – but they do not seem to produce an old-style plist or any kind of encoded string. Instead, the output seems to be binary-encoded. This can be tested by installing pyobjc and then running from Foundation import *; bytes(NSSerializer.serializePropertyList_({"Hello": "World"})) and inspecting the resulting bytes.
The OpenStep spec does not specify what output format NSSerializer produces, it just says it produces 'an abstract representation of a property list [...] in an architecture-independent format': https://www.gnustep.org/resources/OpenStepSpec/FoundationKit/Classes/NSSerializer.html
When encoding to XML using the replacement for NSSerializer - NSPropertyListSerialization – it does seem to produce NSData representing a string. This sounds similar to what the Wikipedia article is claiming. It can be tested using pyobjc with the command from Foundation import *; bytes(NSPropertyListSerialization.dataWithPropertyList_format_options_error_({"Hello": "World"}, NSPropertyListXMLFormat_v1_0, 0, None)[0]).
The GNUStep docs mention that the output of NSSerializer is NSData that actually represents a string. That sounds very much like what the Wikipedia article talks about, but it seems to only apply to GNUStep not to macOS - perhaps the this is the origin of the misunderstanding? https://www.gnustep.org/resources/documentation/Developer/Base/Reference/NSSerialization.html#class$NSSerializer

92.117.213.226 (talk) 16:32, 22 April 2025 (UTC)[reply]

Context: I dug into this because I wanted to find out if there's still a way to create an old-style plist on modern macOS. So far I couldn't find a way, but I think there has to be one, since Xcode's own .pbxproj files are still old-style plists – with comments! – Something that neither JSON nor modern XML plists support. 92.117.213.226 (talk) 17:12, 22 April 2025 (UTC)[reply]

[1] ttps://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node108.html

[2] ttps://www.cs.cmu.edu/~dst/LispBook/

[1]

[2]