Is plist an XML?

 

Apple’s Property List XML Is Pointless

Apple has a data format called “property lists” (or “PLists” for short). It is basically a heirarchy of lists, maps, and a few primitive types (like strings, booleans, etc.). It’s very much like using a Python/Ruby/Perl structure of lists/arrays and dicts/hashes to represent a tree of data.

Apple supports three ways of representing PLists:

• "Old-style ASCII" - A faily easy to read/write representation.
• Binary - A more efficient representation.
• XML - A XML-ized representation.

Originally, there were only ASCII and Binary PLists. But, for some reason, Apple created XML PLists and decided to make them “the preferred way to store property lists”.

Now, I think XML is a horrible format. But even ignoring XML’s crappiness, PList XML is still completely pointless.

For some reason, people read this and think I’m bashing PLists. I’m not. PLists are fine. The Old-style ASCII syntax is concise and readable and the binary format is efficient. It’s just the XML storage format that sucks.

Why PList XML Can’t Leverage XML Tools

Normally, the standard argument is that using XML lets you leverage existing tools. But PList XML doesn’t really use XML, it just beats it into submission. Because XML can’t directly support the types of data structures needed by PLists, Apple was forced to create an entire opaque layer on top of XML. Take the following ASCII PList, for example:

{
  Dogs = (
    {
      Name = "Scooby Doo"
      Age = 43
      Colors = (Brown, Black)
    }
  )
}

A natural translation to XML might look something like:

<Config>
  <Dogs>
    <Dog>
      <Name>Scooby Doo</Name>
      <Age>43</Age>
      <Colors>
        <Color>Black</Color>
        <Color>Brown</Color>
      </Colors>
    </Dog>
  </Dogs>
</Config>

The PList XML version looks like this:

<dict>
  <key>Dogs</key>
  <array>
    <dict>
      <key>Name</key>
      <string>Scooby Doo</string>
      <key>Age</key>
      <integer>43</integer>
      <key>Colors</key>
      <array>
        <string>Brown</string>
        <string>Black</string>
      </array>
    </dict>
  </array>
</dict>

The result: something that’s even more verbose and harder to read than a natural XML format.

Bad arguments in support of PList XML

Though the creation of the XML format was completely useless, some people will try to justify it anyway. All the stupid pro-XML arguments in this section were made by actual people in a long Slashdot discussion.

XML Validation

"XML is self-validating.".

I’m not sure what self-validating means. I suppose it could mean that the format is defined such that any possible file is a valid file (therefore any file would trivially be a valid file), but this is not true of XML. Maybe he meant that you could leverage existing XML validation tools, but that is untrue as well.

If you used a natural XML format, you could use DTD/Schema/RelaxNG/whatever to create a type definition for your config format and use a validating parser to automatically check all input files.

With PList XML, you cannot do this because Apple has already “used up” the validation on all their own tags (<dict>, <array>, etc.); you’re on your own when validating the actual key/value pairs. In essence, you can only use XML validation to take care of the overhead created by XML in the first place; it’s a zero-sum setup. All you get is an unreadable format and a performance degredation.

Disabling Validation

One guy said that declarative validation can sometimes be more of a hindrance than a help and that it’s easier to use free-form PLists.

Nobody said you have to use a validator. The point is that if you use XML directly, you can use a validator if you want. If you use PList XML, that’s not even an option.

Editor Support

If you have a DTD/Schema/RelaxNG spec describing your data structure, there are editors that will help you out by offering code-completion and other features to make editing easier.

If you use PList XML, the editor will only auto-complete the trivial tags (<dict>, <array>, etc.). If you use the ASCII PList format, you wouldn’t even need the auto-completion because those tags (which are just overhead) don’t even exist.

Efficiency doesn’t matter

"Computers are so fast that the tiny inefficiencies of XML’s format don’t matter."

You could forgive XML’s inefficiencies if there were any benefits to counter them, but there aren’t. Even if the inefficiences are small, relative to the benefits (none), they are infinite.

Using XML libraries

"The PList implementation can rely on well-tested XML libraries."

This might be almost valid if ASCII PLists either didn’t exist or were difficult to parse.

Apple already has a parser for ASCII PLists, which I expect they’ll have to continue maintaining. I’m sure the parser is well-tested and efficient. The nature of ASCII PLists makes bugs less likely since the format is so simple.

Even if they didn’t have a parser already, I’m sure a 100-line Flex file could have done the job just fine. For someone already familiar with Flex (and I’m sure many Apple employees are), creating a parser for ASCII PLists might even be less work than interfacing with an XML library to parse PList XML.

Unicode

“PList XML supports Unicode.”

Yes, and the ASCII PList format doesn’t. However, when you look at the opportunity cost, it would have been cheaper for Apple to enhance ASCII PLists to allow for different character encodings than to create a parser for PList XML.

All you really need is a simple directive at the top that sets the encoding. That’s all XML does. It’s not rocket science.