Comments on: Does anyone know why the Mac OSX property list (pflist) file format is such a bastardization of XML?

Question: Does anyone know why the Mac OSX property list (pflist) file format is such a bastardization of XML?

robinw — Wed, 29 Dec 2004 12:36:27 -0800

Does anyone know why the Mac OSX property list (pflist) file format is such a bastardization of XML?

It looks like XML, except it doesn't form a proper tree.

By: andrew cooke

andrew cooke — Wed, 29 Dec 2004 12:40:17 -0800

eh? it is standard xml. what do you mean?

By: andrew cooke

andrew cooke — Wed, 29 Dec 2004 12:45:52 -0800

(as long as it nests - every opened element closes and no two elements "overlap" - then it is a tree. trees don't have to have all branches "teh same" in some way)

By: nicwolff

nicwolff — Wed, 29 Dec 2004 12:52:36 -0800

It's valid XML, but the DTD is general to key-value "property lists" rather than to the particular properties being listed. They're meant to be read to and from data structure with the Cocoa property-list API, not manipulated with XPath.

By: xil

xil — Wed, 29 Dec 2004 12:52:57 -0800

That link doesn't actually describe the format of a generic plist, it just gives descriptions of the keys in a specific plist. A better example of the XML is here. Also note the DTD which describes the format.

By: smackfu

smackfu — Wed, 29 Dec 2004 12:59:07 -0800

Good question. It does honestly look like something someone would design right after discovering XML, before they knew better.

By: robinw

robinw — Wed, 29 Dec 2004 13:01:29 -0800

Okay, I apologize. It is a valid document in the sense that it validates, but it isn't valid in the sense that it's not logically arranged. For example, from xil's link, you can see that a particular key/value pair is not separated by a sub-tree. The only way to find out when the current key/value pair ends is by the next node having another key.

Why go to so much work making it look like XML, only to arrange it completely illogically? They could have added one simple wrapper node to each key/value pair and it would have been perfect.

It's not easily parseable by man, nor machine.

By: sbutler

sbutler — Wed, 29 Dec 2004 13:04:05 -0800

I know some people are pissed that plist files rely on the order of the elements, not just that they exist. For example, an entry in a dictionary is:

<key>some key</key>
<string>some value</key>

instead of something more verbose, like

<entry>
<key>some key</key>
<string>some value</key>
</entry>

But I don't remember anything in the XML spec that says sibling order can be ignored -- so Apple is completely within its right. I rather like the more compact way they did it.

incidentally, Sun went the verbose route with Servlets/JSP and the deployment descriptor. Try typing one of those out by hand sometime: it truly sucks.

(on preview: what robinw said, but I disagree. Seems like a perfectly valid design choice to me)

By: sbutler

sbutler — Wed, 29 Dec 2004 13:05:36 -0800

ermm.. foiled again by copy and paste! please excuse my obviously invalid XML

By: andrew cooke

andrew cooke — Wed, 29 Dec 2004 13:13:36 -0800

oh, ok.
you could probably write an xslt transform that collects together key/value pairs and inserts an extra element round them. then filter your data through that. or parse with a stream interface (sax), which makes changing state in this way fairly simple.
imho, this is a problem because tools don't use the dtd sufficiently. if you look at the dtd, the structure is pretty obvious (it's an elegant recursive definition, just like you'd write in a functional language).

By: andrew cooke

andrew cooke — Wed, 29 Dec 2004 13:15:59 -0800

(in fact, you might find that a fancy xml parser for (extended) haskell generates data structures from that dtd just like you'd write yourself.)

By: andrew cooke

andrew cooke — Wed, 29 Dec 2004 13:17:30 -0800

generates data structures -> generates types and code (to generate typed structures from the xml)

By: nicwolff

nicwolff — Wed, 29 Dec 2004 13:26:44 -0800

The only way to find out when the current key/value pair ends is by the next node having another key.

Huh? It's a pair. <!ELEMENT dict (key, %plistObject;)*>. Man, or machine, can use XSL's following-sibling selector to easily parse and transform plists.

By: robinw

robinw — Wed, 29 Dec 2004 13:35:42 -0800

Touché.

By: nicwolff

nicwolff — Wed, 29 Dec 2004 14:04:51 -0800

Not to snark, but I knew little about XSL and DTDs and nothing about XSL before I googled "plist xml" after reading your question. So, I thank you for the opportunity to educate myself but my clients hate us both now for the work time lost...

By: nicwolff

nicwolff — Wed, 29 Dec 2004 14:05:55 -0800

Oh, wait, you thought it was "pflist" - it's "plist" - never mind, you wouldn't have found it.