Print

Print


Makes sense to me!

On 2/19/14 5:02 PM, LeVan,Ralph wrote:
> 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.
>
> Ralph
>
> -----Original Message-----
> 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
>>> about
>> doing content
>>
>>> negotiation at the record level?  Can you give an example.
>>
>> http://rdap02pxdu.dev.oclc.org:8080/viaf/search?query=local.names+all+
>> %22ralph%20levan%22&httpAccept=application/json
>>
>> 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=applicati
>> 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
>> 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.
>>
>> Ralph
>>
>> 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
>>
>> http://rdap02pxdu.dev.oclc.org:8080/viaf/search?query=local.names+all+
>> %22ralph%20levan%22&recordPacking=string&recordSchema=JSON&httpAccept=application/json
>>