Data file format and response format

24May08

I have been thinking some about the format of the data file, and the format of the response.

To make the service resemble XMLWebservice Im thinking of dividing the URIs to where the POST data is sent(Thanks Kuno). One for adding, one for removing. And also it might be a good idea to also separate “tracklist” and “albumlist” to different URIs. Feedback please 🙂

My idea right now of the data file format is like this:

version:version name goes here

begin public collection name of collection here
begin tracklist
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end tracklist

begin albumlist
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end albumlist
end collection name of collection here

 

Where those series of X represent UUIDs of a MBID. There is two types of lists – albumlist and tracklist. Tracklist contains UUIDs for tracks, albumlist UUIDs for albums(releases).

I named it album instead of release, because I believe they will be named albums in NGS?

This format is supposed to facilitate all features, including the “nice to have” ones.
Is there some other format used in Musicbrainz? Something that I should make this format resemble?

I also made a rough sketch on the response format. See following:

<?xml version="1.0" encoding="ISO-8859-1"?>
      <response>
          <details uuidtype="track">
               <addcount>123</addcount>
               <removecount>456</removecount>
               <error>
                    <errorstring>Error message as string here</errorstring>
               </error>
          </details>
          <details uuidtype="album">
               <addcount>12</addcount>
               <removecount>34</removecount>
               <error>
                    <errorstring>Error message as string here</errorstring>
               </error>
          </details>
</response>

 

 

The “details” name is bad in my opinion. Could not come up with anything better. Will revise it.
Both addcount and removecount should not be in the same response though. Theyre just both there to illustrate that they are available.

Im going to make another blog post soon about other updates and comments.

Advertisements


11 Responses to “Data file format and response format”

  1. 1 Nikki

    While I’m not entirely sure what ‘release’ will mean exactly in NGS, we moved away from using ‘album’ so I can’t see people going back to using it.

  2. 2 mafr

    XMLWebService uses the REST architectural schema (see wikipedia or Fieldings’ dissertation), so it’s not quite as easy as posting something to an URL. I designed that web service and it wasn’t entirely trivial, I can tell you 😉

    Regarding the response format: You might want to use an XML namespace and expand the error element a bit. Client libraries probably want to raise different types of exceptions depending on the type of error, so a machine-readable error code would make sense. A free-text error string is still good and useful.

  3. 3 kuno

    I would move the version into the URL, like the current musicbrainz webservices have. For example if you stick to your current protocol, you can easily move to XML later if the version is part of the URL and not part of the data being sent.

    Something else which is probably import to mention:

    Do not dwell on this too long, it is something which can easily be changed later on in the project. You will quickly discover things you missed as you start implementing, so do not try to think of everything in advance.

  4. 4 niklas

    Thank you for the replies. Will write a small update hopefully by tonight.
    Will include some more GET parameters, alternatively divide into more resources.

    Nikki: good

    mafr: yes, this was the idea with having the error entity with sub-entities. dont know why I did not include it right away. thanks! looked into REST, but not sure how to make this more “RESTful”

    kuno: will move it. I want to “finalize”(for now) this as soon as possible. school is coming to an end and I want to start coding 🙂

  5. 5 niklas

    Im not going to write an update. Not much to change.

  6. 6 ijabz

    I dont quite follow the example data , are you advocating sending a physical data file rather then sending the data as post parameters. If so I don’t agree you shouldnt impose this restriction some applications may not have access a filesystem, and creating a file is an unneccssary step anyway..

    What about these post parameters instead:
    action=add
    tracklist=trackid1,trackid2
    releaselist=releaseid1

    would add trackid1,trackid2 and releaseid1

    action=remove
    tracklist=trackid1,trackid2

    would remove trackid1,trackid2

    I guess the following idea has probably been thrown out already but a simpler alternative approach would could be just be for the server to parse tags entities that are currently being tagged with the ‘owned’ tag using the folksonomy service

  7. 7 niklas

    “I dont quite follow the example data , are you advocating sending a physical data file rather then sending the data as post parameters. If so I don’t agree you shouldnt impose this restriction some applications may not have access a filesystem, and creating a file is an unneccssary step anyway..”

    Yes, I was thinking of producing a file to send, but thats so stupid. Thank you for the feedback, will do another post!

    “I guess the following idea has probably been thrown out already but a simpler alternative approach would could be just be for the server to parse tags entities that are currently being tagged with the ‘owned’ tag using the folksonomy service”

    Would this require people to manually tag music as owned? Or can this be done automatically with e.g. Picard or Jaikoz somehow?

    Working on an exam today, got another one tomorrow morning. That will be my last one. After that expect to see more updates…

  8. 8 ijabz

    Currently tracks are tagged with ‘owned’ through the website but there is already a webservice for adding tags to a artist/release/track/label so it could easily be done programatically. In fact in the dev version of Jaikoz I can submit genres to tags at a track level , so by entering ‘owned’ instead of a genre into the genre field i can hack it to do this already.

  9. 9 ijabz

    I mentioned using owned on irc, bad idea, not really robust enough. But you could take the cut and paste the folksonomy webservice code for your project

  10. Not that I’m totally impressed, but this is more than I expected when I found a link on Furl telling that the info here is quite decent. Thanks.

  11. I used to be able to find good advice from
    your blog posts.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: