Years ago, I was on the editorial board for versions 1.1 and 1.2 an informal standard called SRU. It defined a way to do IR queries over HTTP with XML payloads: you’d send a URL like http://example.com/dbname?someBoringStuff&query=fish, and it would send back an XML document describing the search result — hit count, that kind of thing — and containing payload records.
Since the payload records themselves were also in XML, it was often convenient to just embed them right in the response, where they could be extracted by XSLT or similar. On the other hand, other applications preferred to have the records be XML-safe blobs that could be extracted and treated separately. (One reason for this is that it was the Bad Old Days when much of the XML out there was not valid or even well-formed, so we needed a way to ensure that a single bad payload record didn’t break the whole response.)
Requests could specify how to pack payload records using the recordPacking parameter, which could take the value “xml” or “string“. Other request parameters included things like maximumRecords (include no more than this number in the response) and recordSchema (whether to return the payload data as Dublin Core records, MARCXML, or some other schema).
A few years later, the SRU 1.2 specifications were adopted by a subcommittee of OASIS, a proper standards body, and immediately changed out of all recognition into SRU 2.0, an incompatible specification that has the advantage of being formally recognised as a standard, but the disadvantages of several incomprehensible technical decisions. It became part of a wider all-things-to-all-men initiative known as searchRetrieve v1.0.
I’ve mostly been able to ignore SRU v2.0, but a few days ago this observation cropped up on the SRU mailing list (which I’m still on for historical reasons):
The parameter recordXMLEncoding is introduced in 2.0, replacing the 1.2 recordPacking parameter (and a new recordPacking parameter is introduced, with different semantics). […]
The recordPacking parameter in 2.0 has completely different meaning than in 1.2. […] In short, it tells the server whether or not to take seriously the parameter recordSchema: if it is omitted or its value is ‘packed’ then the server MUST supply records according to the requested schema. If it is supplied with the value ‘unpacked’ then the server is free to choose an alternative schema.
what is this i dont even