Apple, XML, and the Music Store

Thanks to Tim Bray, we now know that there is an XML interface to the Apple Music Store. In the search for more information to understand what was provided to us and what they were getting from users buying information, I checked inside the actual track XML. In this case, I picked an XML sample file from their site and dissected it. This is all very geeky so if you’re not interested in the Apple store or in XML, no need to read on.

The following basically tells us that we are dealing with an XML document.


It’s encoded in UTF-8, a format that allows to show the largest possible set of characters. This clearly shows that Apple intends the store to be something that they will use beyond the US as they might plan to use foreign characters in their XML definition.

Also of interest here is the note about standalone being no. This means that there is no interest in the document not being part of an application (ie. the store).

Next up is the page definition:


Of interest here is the fact that they differentiate the different pages. This one is the result of a search so the pageType is set to search. I haven’t yet fiddled with other pages but I suspect that they have other potential use for this.

Once you’ve got your document defined, they break it down into three elements:
Path, ScrollView and TrackList. Let’s look at those now.

The Path Element

The Path element basically provides information as to where the document resides. Under the tag, you find a sub-element called PathElement. It shows up as follows:

 /WebObjects/MZSearch.woa/21/wa/advancedSearchResults?songTerm=Morritz%20Discovers%20the%20Red%20Violin

Now what we have here is a page called “Search Results for: Morritz Discovers the Red Violin” which is located at http://phobos.apple.com/WebObjects/MZSearch.woa/21/wa/advancedSearchResults?songTerm=Morritz%20Discovers%20the%20Red%20Violin

Basically, what it gives is the location of the document. Nothing to find here.

The ScrollView Element

This one is a monster of information related to how to display things on the screen. Of interest here is the fact that they position everything using a new form of XML and using outside pointer files for font handling. It looks like Apple is using some WebObject syntax to position their elements on a page. Why they decided to do so is obvious when you realize the NeXT used to be Steve Jobs company and the Apple store is running WebObject.

However, it would have been much nicer if they were to do this as plain XHTML + CSS or XML + XSL. The syntax used in their file is bulky at best and, unfortunately, can only be parsed by using one of their tools right now.

The TrackList Element

This element describes metadata about the particular track (or tracks) you’re looking for. It’s using Apple’s Property List.

This is a great throve of data for anyone who might, in the future, want to develop a service that integrates with the Apple store. Let’s look at it in more details.

The first thing it does is tell you what type of list you’re dealing with:

listType
search

Basically, all it’s doing here is telling you that this is a list that was the result of a search.

priceFormat
$%0.2f

This tells you that the price format is in tenth of a cent. An interesting thing as it seems to open up the potential for microtransaction in the future. Based on the model they seem to be adopting, you could technically go much lower than that, which shows some potential for a future where you might end up paying less than a cent per track. Interesting.

The next key is items. This can list several item. For the purpose of this example, I actually looked for a search result that would return a single item but the same logic applies here whether you have one or many items. The string looks as follows:

Items

… and it is followed by an array that list each item.

So what info do we get about an item in the Apple store?

So here’s the real meat: What makes a track special. Everything here seems to be based on a key-value pair. I’m now building up a table that will show how each relates:

kind string track This seems to show whether an item is a track or an album. I would assume that this could eventually expand to video, or other media format
artistName string Joshua Bell, Philharmonia Orchestra, Esa-Pekka Salonen This is basically, the name of the artist
artistId string 462760 An internal id. Why didn’t they use an integer here?
bitRate Integer 128 The bitrate at which the track is recorded. I would assume that they might plan to offer different bitrates at different prices in the future.
buyParams string productType=S&salableAdamId=477149&price=990 Looks like a buying parameter. I suspect this is used to construct the URL. It seems a little odd to have that embedded when the other information is already in the file. Having the price show up in two locations seems to generate extra overhead that is unecessary, unless they are looking to sell items at different prices to different people. But the, why would it be in the XML fields?
price integer 990 Interesting. This is in tenth of a cent. Could we see an eventual sale of tracks for less than one cent?
composerName string JOHN CORIGLIANO (b.1938) Probably more sorting metadata but also useful for them in terms of tracking which composer to remunerate. Why is the composer’s birth year in there?
composerId string 462764 Why is this value a string and not an integer? Either way, it’s useful for apple as it allows them to track which composer they need to pay.
copyright string 1999 SONY CLASSICAL This is the copyright info for that track.
dateModified date 2003-04-25T02:17:02Z I suspect this is the date when the entry was modified. This allows them to refresh data and keep track of when it was last updated
discCount integer 1 I wonder if that’s the number of disc on which the track appears.
discNumber integer 1 Related to the field above?
duration integer 220000 Duration of the track in milliseconds?
explicit integer 0 This, I suspect, is to track whether a song has explicit lyrics or not. My suspicion is that the value is set to 0 if it does not and one if it does. I could foresee Apple coming out with a “clean” version of the store that would be controlled through some parent-driven filter.
fileExtension string m4p This would allow Apple to sell different media types in their store. If, for some reason, they had to move beyond the existing format, they would do it here. It also points to the possibility of their selling other media types from the store.
genre string Soundtrack This is a basic classification field.
genreId integer 16 An ID linked to the classification seen above.
playlistName string The Red Violin (Soundtrack from the
Motion Picture)
I suspect this is the name of the album on which the track appears.
playlistArtistName string Joshua Bell, Philharmonia Orchestra,
Esa-Pekka Salonen & The Red Violin
And, as above, this would be the artist for the whole album.
playlistArtistId integer 462760 This is a unique number to identify the artist for the whole album.
playlistId string 462767 This seems to be an internal id for the album. However, I don’t know why they would use a string here instead of an integer.
previewURL string http://a1328.phobos.apple.com
/Music/
y2003/m04/d11/h02/
s03.vyadggbi.p.m4p
This, I believe, is where the 30 second preview for the track resides. Of interest here is the classification. Notice that there is a Music directory in that URL. This seems to point to the fact that Apple is envisioning eventually selling videos or other media types. The URL is then broken down into year, month, day, hour, and… minutes? This might be a mechanism to rotate things and track when things are played, I suspect.
relevance string 1.0 I suspect that this is a relevance ranking based on how relevant the track is to your search.
releaseDate string 1999-05-18T07:00:00Z When the album was released? Why is this a string instead of a date?
sampleRate integer 44100 This gives information as to what the sample rate of the track is. This could point to Apple eventually intending to sell tracks at different sample rates.
songId integer 477149 A unique reference ID for that song
comments string currently empty Does that mean that we will see reviews from Apple here? Or maybe a user-based rating system similar to Amazon?
trackCount integer 20 Number of songs on the album
trackNumber integer 16 Number of that particular song on the album. In this case, it’s the 16th song in a group of 20.
songName string Morritz Discovers the Red Violin The title of the song
year integer 1999 The year the song was published

So Apple provides a lot of information in this. For starters, I’d like to compliment them on the breadth of metadata they provide on each track. This is clearly a great value add to anyone who wants properly tagged music. However, it seems that they could offer the tracks in other formats (MP3, or Ogg Vorbis, maybe? ).

The other interesting thing when reading this file is what it reveals as to future potential. It is pretty clear that they plan to offer the system worldwide. It is also interesting that they classify things like media types as it could open up the potential for the Apple movie store in the future. Also of interest was the choice in terms of how small the currency increments are as it could point to Apple eventually looking to sell things for less than a cent. Could we be looking at a rental system in the future? However, there is no information here yet as to what they get from us in terms of data. I’d still like to know that and, if anyone has pointers, would be interested in reading more about it.

Last but not least is why is it that Apple decided to create their own metadata when other solutions (such as the ID3 system used in MP3s) seem to provide similar info? Some of it points to the potential for a proprietary closed system but, by publishing this data in the open, it seems that Apple is willing to take a step in the right direction, that of openness.

My guess is that they will soon offer a web service interface to the store, similar to the one offered by Amazon. It makes sense as it would allow a whole new community of developers to create applications that would drive more money into Apple. However, without a clear understanding as to the DRM setup, it is difficult to estimate what benefit others might get from this.

Previous Post
1984 Redux
Next Post
Doing Bad by Doing Good
%d bloggers like this: