You are absolutely correct. The correct negotiation request would be: application/ld+json, application/json;q=0.9
That says, I want JSONLD, but will accept any JSON. I *don't* get to just pick another JSON format if they asked only for ld+json. But, given the recordAccept (yes, I just coined that name now) parameter above, I *would* be allowed to return application/vnd.oclc.viaf+json if I wasn't able to return application/ld+json.
From: SRU (Search and Retrieve Via URL) Implementors [mailto:[log in to unmask]] On Behalf Of Jonathan Rochkind
Sent: Wednesday, February 19, 2014 4:44 PM
To: [log in to unmask]
Subject: Re: SRU recordPacking and JSON
I'm wondering whether it actually makes sense at all to content negotiate to a different JSON-based format then the one you think they are asking for?
Does someone have a use case where software asking for one JSON-based format, but which gets a different JSON-based format instead, is still going to be able to do something useful with it? It's not something I've encountered myself.
Even for "+xml" content types (which actually are standardized -- every content type ending in "+xml" must, by standard, be an XML type; the same is not true of "+json") -- I don't _think_ conneg usually works such that a client asking for only "something+xml" is given "other+xml"
instead -- rather than an error message saying "something+xml" can not be provided.
On 2/19/14 4:13 PM, LeVan,Ralph wrote:
>> Sure, it's just as sensible, the concept is good. But how you go
> 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.)
> on/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
> 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