Print

Print


I don't think that recordSchema can be deprecated; it still makes sense for XML and there is also the concept of a schema in JSON land to describe the format of JSON data.

I agree that it seems sensible to allow:

* packing a record as XML in a XML SRU response
* packing a record as JSON in a JSON SRU response
* packing a record as XML in a JSON SRU response
* packing a record as JSON in a XML SRU response

Best,
John

[1]: http://json-schema.org/


On 18 Feb 2014, at 08:53, Jörg Prante <[log in to unmask]> wrote:

> From what I understand, "recordPacking" was trying to carry information
> of what Z39.50 OIDs did in 1.2.840.10003.5.109.x
> http://www.loc.gov/z3950/agency/defns/oids.html
> 
> But today, is there any SRU service which is not working over HTTP (I
> do not mean Z39.50 over SRU)?
> 
> There is the MIME type application/sru+xml
> https://tools.ietf.org/html/rfc6207 which is also meant for use in
> the HTTP header "Accept" for content negotation.
> 
> I think it's time for SRU / SearchRetrieve to fully embrace HTTP
> content negotiation, and REST - I mean, most importantly, the HTTP
> status codes. Therefore, I would welcome deprecating the parameter
> "recordPacking", and also "recordSchema". 
> 
> If content negotiation is not sufficient, it could be an option to use
> HTTP headers for additional hinting, for XML schemas, bibliographic
> field formats etc. HTTP headers could also carry Z39.50 OIDs in their
> full extent, by preceding the header name with something like
> "X-Z3950-...", or optional SRU parameters, in "X-SRU-..."
> 
> Here's my proposal. This is an SRU request for XML
> 
> GET /sru/...
> Host: localhost
> Accept: application/sru+xml
> ->
> HTTP/1.1 200 OK
> Content-Type: application/sru+xml
> 
> and this is for JSON
> 
> GET /sru/...
> Host: localhost
> Accept: application/sru+json
> ->
> HTTP/1.1 200 OK
> Content-Type: application/sru+json
> 
> or even, with HTTP content negotiation, both are possible:
> 
> GET /sru/...
> Host: localhost
> Accept: application/sru+xml,application/sru+json
> ->
> HTTP/1.1 200 OK
> Content-Type: application/sru+xml
> 
> And also something for RDF serializations, because Bibframe is coming
> close.
> 
> I have only JSON-LD, so over the SRU endpoint, I would also like to
> perform RESTful actions on RDF graphs, like
> 
> GET /sru/...
> Host: localhost
> Accept: application/ld+json
> ->
> HTTP/1.1 200 OK
> Content-Type: application/ld+json
> 
> Such requests lack any information about "recordSchema",
> "recordPacking", OIDs, Z39.50, simply because there is none such
> information. If it was, it's all encoded in the JSON-LD.
> 
> HTTP GET requests are stateless. So I'd like to drop SRU parameter
> "resultSetTTL". Was this ever used, clients enforcing servers to keep
> result sets, for days or weeks, or even longer? If so, it could be
> replaced by URL- or cookie-based session life times, under control of
> the server.
> 
> Best,
> 
> Jörg
> 
> 
>>>> "LeVan,Ralph" <[log in to unmask]> schrieb am 17.02.2014 um 21.27 Uhr
> in Nachricht
> <[log in to unmask]>:
>> I'm playing around with JSON and SRU.  My server has pretty decent
> support 
>> for content negotiation and I've started explaining to it how to
> handle 
>> requests for JSON.
>> 
>> 
> http://rdap02pxdu.dev.oclc.org:8080/viaf/search?query=local.names+all+%22ral
>> ph%20levan%22&httpAccept=application/json
>> 
>> That's a simple name search, with a request that the response be in
> JSON.  
>> You'll notice that the recordPacking is "xml", which is appropriate,
> because 
>> the records are returned as XML.  But, as far as JSON is concerned,
> what I 
>> returned was a string.  (The value of recordData in JSON is of type
> string.)  
>> What happens if I want to return JSON records?  How do I even ask for
> JSON 
>> records?
>> 
>> Right now, to return JSON records I have to say that the
> recordPacking is 
>> "string" (because it sure isn't "xml") and pick a recordSchema of
> JSON 
>> (because there's no other place to say you want JSON.
>> 
> http://rdap02pxdu.dev.oclc.org:8080/viaf/search?query=local.names+all+%22ral
>> 
> ph%20levan%22&recordPacking=string&recordSchema=JSON&httpAccept=application/json
>> 
>> 
>> I think the recordPacking was intended to be the mimeType of the
> record, as 
>> opposed to the httpAccept, which is the mimeType of the response.  I
> think 
>> the recordSchema was intended to talk about the logical content of
> the 
>> record, not the physical format.  In my particular case, I already
> have 
>> multiple schemas that I want to return my data in (LinkedData,
> Marc21, 
>> VIAFCluster), regardless of the mimeType that the record is returned
> in.
>> 
>> My suggestion is that we expand the meaning of recordPacking to mean
> 
>> mimeType of the recordData and grandfather in the special values of
> "string" 
>> to mean "text/plain" and "xml" to mean "text/xml".  If you return
> text/plain 
>> records in a text/xml response, it is up to the application to make
> the 
>> records safe in the XML (meaning escaping the appropriate characters
> in the 
>> string.)  That same would be expected in JSON (where the string would
> just 
>> get quotes around it.)
>> 
>> Does this seem sensible?  Is anyone else doing anything like this?
>> 
>> Thanks!
>> 
>> Ralph
> 
> 
> 
> 
> -- 
> Jörg Prante
> hbz, Gruppe Portale
> - Digitale Bibliothek und Online-Fernleihe -
> Postfach 270451, 50510 Köln, Deutschland
> Telefon +49-221-40075-156, Fax +49-221-40075-190
> [log in to unmask]
> http://www.hbz-nrw.de

John Harrison
University of Liverpool
e: [log in to unmask]
w: cheshire3.org
t: 0151 7943921