NSColor archiving weirdness

This is what an NSColor looks like in a xml keyed archive:

  <dict>
   <key>$class</key>
   <dict>
    <key>CF$UID</key>
    <integer>18</integer>
   </dict>
   <key>NSColorSpace</key>
   <integer>1</integer>
   <key>NSRGB</key>
   <data>
   MC4zNzY0MDQ0OSAwLjUxMTIzNTk1IDAuNjQ5ODEyNzYgMC42MwA=
   </data>
  </dict>

There are numerous variations on this, but it is basically a color space and then appropriate values. Since this is a property list the gook between the <data>'s is base64.

Now, the question at hand is, what's in the data? The first instinct might be perhaps that since this is an NSData, the information is binary encoded, perhaps some big endian floats or doubles? Nope. Perhaps some super secret binary format? Nope.

It's just an ASCII string:

MC4zNzY0MDQ0OSAwLjUxMTIzNTk1IDAuNjQ5ODEyNzYgMC42MwA=

Equals:

0.37640449 0.51123595 0.64981276 0.63

Now at this point you're kind of going "So f'ing what?". Well, I'm saying "What the f?"

What is the reason for doing this?

Space savings? Not really.

<data>MC4zNzY0MDQ0OSAwLjUxMTIzNTk1IDAuNjQ5ODEyNzYgMC42MwA=</data>
<string>0.37640449 0.51123595 0.64981276 0.63</string>

<data>MAA=</data>
<string>0</string>

Speed? Nope. The base64 adds yet another layer of parsing at the very least.

Precision? Nope. They represent the same thing.

Obscurity? Barely.

Backward compatibility? With what? keyed archivers are relatively new.

Care to guess? Even in binary archives this decision makes little sense.

Keyed archives provide this nice way of generating human readable archives and yet NSColor ruins the party and writes out strings as data. We waited so long for text archives and this is what we get? Bleh.