> Sure, it's just as sensible, the concept is good. But how you go about doing content
> negotiation at the record level? Can you give an example.
Here’s a generic request for an SRU response in JSON. It doesn’t say anything about how the records should be returned, but certainly implies that they should be in JSON too. (Sadly, it gets an XML record now, because I’m not doing record content negotiation yet.) Right now, I have two different JSON schemas: vnd.oclc.viaf+json (that’s my VIAF XML record run through a lovely mechanical XML->JSON translator) and ld+json (that’s a hand-built implementation of the current Linked Data in JSON proposal). I’d propose specifying them using recordSchema (that being the closest match we have.)
http://rdap02pxdu.dev.oclc.org:8080/viaf/search?query=local.names+all+%22ralph%20levan%22&httpAccept=application/json&recordSchema=application/ld%2Bjson (Sadly, that URL gets you a nice SRU diagnostic returned as JSON, because that recordSchema isn’t recognized yet. I’m really hoping for some feedback on the idea before I implement record content negotiation.)
Now, if they asked for application/bob+json, then we fall into regular HTTP negotiation and I’d return what I thought was my best JSON and I’d tell them they were getting application/vnd.oclc.viaf+json in the recordSchema element (or whatever they get called in JSON) of the record response.
p.s. Here’s the hack I’m using right now to get that VIAF record in JSON. Like I said, I’m looking for a cleaner way to do this that doesn’t make you all gag. J