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
|