ITunes XML



  • I mostly wanted to post this since it's from a company I'd expect to know better, but apparently not. It seems someone at apple wanted the synergy and paradigm shifting of xml without the utility...

    <?xml version="1.0" encoding='UTF-8' standalone="yes"?>
    <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
      <dict>
        <key>Major Version</key><integer>1</integer>
        <key>Minor Version</key><integer>1</integer>
        <key>Application Version</key><string>4.1.1</string>
        <key>Tracks</key>
        <dict>
          <key>0</key>
          <dict>
            <key>Track ID</key><integer>0</integer>
            <key>Name</key><string>DoD</string>
            <key>Artist</key><string>Zoast</string>
            <key>Album</key><string>music</string>
            <key>Genre</key><string></string>
            <key>Comments</key><string></string>
            <key>Kind</key><string>MPEG audio file</string>
            <key>Size</key><integer>9302</integer>
            <key>Total Time</key><integer>378000</integer>
            <key>Date Modified</key><date>Sun Aug 22 21:37:36 2004</date>
            <key>Bitrate</key><integer>201</integer>
            <key>Play Count</key><integer>0</integer>
            <key>Location</key><string>file://localhost/D:/music/Zoast-Zelda-Koji-DoD.mp3/</string>
            <key>File Folder Count</key><integer>-1</integer>
            <key>Library Folder Count</key><integer>-1</integer>
          </dict>
          <key>1</key>
          <dict>
            <key>Track ID</key><integer>1</integer>
            <key>Name</key><string>Iris Requiem 'ARCUS' Arranged</string>
            <key>Artist</key><string>Masaaki Uno, Shinobu Ogawa</string>
            <key>Album</key><string>Music from Yaksa &#38; Arcus Cassette</string>
            <key>Genre</key><string>Game</string>
            <key>Comments</key><string>K25H-4709 from McCarls</string>
            <key>Kind</key><string>MPEG audio file</string>
            <key>Size</key><integer>5072</integer>
            <key>Total Time</key><integer>183000</integer>
            <key>Track Number</key><integer>53</integer>
            <key>Year</key><integer>1988</integer>
            <key>Date Modified</key><date>Sun Oct 31 09:37:00 2004</date>
            <key>Bitrate</key><integer>227</integer>
            <key>Play Count</key><integer>0</integer>
            <key>Location</key><string>file://localhost/D:/music/Yaksa/53%20Iris%20Requiem%20'ARCUS'%20Arranged.mp3/</string>
            <key>File Folder Count</key><integer>-1</integer>
            <key>Library Folder Count</key><integer>-1</integer>
          </dict>
          <key>2</key>
          <dict>
            <key>Track ID</key><integer>2</integer>
            <key>Name</key><string>Over the Rainbow</string>
            <key>Artist</key><string>Masaaki Uno, Shinobu Ogawa</string>
            <key>Album</key><string>Music from Yaksa &#38; Arcus Cassette</string>
            <key>Genre</key><string>Game</string>
            <key>Comments</key><string>K25H-4709 from McCarls</string>
            <key>Kind</key><string>MPEG audio file</string>
            <key>Size</key><integer>7209</integer>
            <key>Total Time</key><integer>230000</integer>
            <key>Track Number</key><integer>52</integer>
            <key>Year</key><integer>1988</integer>
            <key>Date Modified</key><date>Sun Oct 31 09:37:00 2004</date>
            <key>Bitrate</key><integer>256</integer>
            <key>Play Count</key><integer>0</integer>
            <key>Location</key><string>file://localhost/D:/music/Yaksa/52%20Over%20the%20Rainbow.mp3/</string>
            <key>File Folder Count</key><integer>-1</integer>
            <key>Library Folder Count</key><integer>-1</integer>
          </dict>
          <key>3</key>
    ....
          </dict>
        </dict>
      </dict>
    </plist>

    Why it's so simple that they can parse it inside the main import loop, without linking to one of those crappy xml libraries! And they probably do. It may not be the worst around, but it sure seems to be up there.

    (I'm praying the forum doesn't eat all that XML.)



  • Ah, you've discovered the abomination known as an "XML PropertyList". It probably won't surprise readers of this forum to hear that this format is the result of XML-izing an existing format. A propertylist is just a text representation of an NSDictionary (a hashtable-like class).

    Back in the days of OpenStep, property lists used a much simpler format, based on a couple of simple delimiters:

    key-value pairs were represented as:
    name="My Name";
    Arrays were specified this way:
    Ducks=(Huey, Dewey, Louie);
    big blocks of binary data were hex-encoded:
    image=<1a23fc4d34560fe123>;
    and embedded dictionaries were delimited with {}:
    anotherdictionary={name=foo;width=10;};

    This was, of course, too easy to understand, and too simple to parse, so the XML-style propertylists were invented to keep things interesting.

    There's a good comparison here:  http://www.stone.com/The_Cocoa_Files/Legacy_File_Formats.html

     



  • So they XML-serialized a hashmap... big deal...



  • @mbessey said:

    A propertylist is just a text representation of an NSDictionary (a hashtable-like class).


    Not entirely.  The root of a property list can be any NS<type>, pretty much.  Fire up property list editor and create a new property list, click the "new root" button and change its type to, for example, NSArray.  Less immediately useful, but still usable.

    @mbessey said:

    Back in the days of OpenStep, property lists used a much simpler format, based on a couple of simple delimiters:

    [snippage]

    This was, of course, too easy to understand, and too simple to parse, so the XML-style propertylists were invented to keep things interesting.

    Yep.  But they are still easily convertable between formats, you can, for example, open up the itunes library xml file in property list editor and save it in ASCII property list format.

    No, I don't like xml plists either, but you don't _have_ to use them.

    Apple's docs are here - http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/index.html

    Notably,

    @Apple Developer Documentation said:

    A property list can be stored in one of three different ways: in an XML representation, or in an “old-style” ASCII format inherited from OpenStep, or in a binary format. In general, the XML format is preferred over the other two.

    All of the property list types can be serialized in all three formats. However, number and date objects stored in an old-style ASCII plist will be restored as strings.

    Simon



  • <key>Major Version</key><integer>1</integer>

    As opposed to:

    <major_version type="integer">1</major_version>

    Or if you're depending on the names being exactly the same, even this would be better:

    <element><name>Major Version</name><value type="integer">1</value></element>

    Is it even legal to depend on the order of the elements like the original example? And even if it's legal, it's not very smart.

    Heck, YAML would have been so much better, and it even has support for fancy things like embedded mappings and sequences:

    Major Version: 1

    Once again, XML wasn't the answer... [:^)]



  • @RiX0R said:

    Is it even legal to depend on the order of the elements like the original example? And even if it's legal, it's not very smart.


    I'm right with you on the "not very smart"... in this one specific case.  However, there are plenty of cases where depending on the order of elements is the only maintainable way to approach markup design.

    Consider XHTML, for example.  I hope you agree that depending on the order of paragraph elements is more logical and maintainable than insisting that each one have an attribute indicating where on the page it should come... ;)


Log in to reply