 |
 |
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