Version 1.1, 12th January 2004
Messages in all of the operations, both request and response, have a field in which additional information may be provided in the request or response. This is a built in extension mechanism, such that profiles may specify a schema for what to include in this section without requiring the developers to change the basic messages and thus render their implementation uninteroperable with all other servers and clients. It is expected that if there is sufficient demand for a particular piece of additional information, that piece of information will be migrated into the protocol in a later version. In this way, only implemented and useful features will be added in future versions, rather than features which just seem like a good idea.
If the server does not understand a piece of information in an extraRequestData field, it may silently ignore it. This is unlike other many request parameters, where if the server does not implement that particular feature it should respond with a diagnostic. If the particular request requires some confirmation that it has been carried out rather than ignored, then the profile designer should include a field in the extraResponseData.
The semantics of parameters in the request may not be modified by extraRequestData. For example, a x-qt-queryType parameter could not change query to be an SQL query, as a server that does not understand the x-qt-queryType extension would expect the query to be in CQL, and thus be unable to parse it. Instead, the extraData should create a new element for the information.
The semantics of parts of the response may be modified by extensions. It would be possible (though very strange), for example, to replace the recordSchema field in the record structure with you favorite chocolate cookie recipe when the client sends a x-cookieType=chocolate request parameter. The response semantics may be changed in this way only if the client specifically requests the change. Clients should also expect to receive the regular semantics, as servers are at liberty to ignore extraRequestData fields.
ExtraResponseData may be sent that is not connected to the search in the request. For example it may contain cost information regarding the query or information on the server or database supplying the results. This data must, however, have been requested.
The profile designer should also include a parameter name beginning with 'x-' for use with SRU. The SRW/U protocol will never include an official parameter with a name beginning with 'x-'. It is suggested, but not required, that the parameter name be x- followed by an identifier for the profile, followed by the name of the element. For example 'x-theo-onSearchFail' for <theo:onSearchFail>
As the request may be echoed in SRU, the server must be able to transform the parameters into their XML form. If it encounters an unrecognised parameter, the server may either make its best guess as to how to transform the parameter, or simply not return it at all. It should not, however, add an undefined namespace to the element as this would invalidate the response.
If the contents of the parameter is an XML structure, then the profile designer should also specify how to encode this structure for SRU. This may simply be to escape all of the special characters, but the designer could also create a string encoding form with rules as to how to generate the XML in much the same fashion as the relationship between CQL and XCQL.
An example of how to define an extension is available.
The only requirement for the extra data fields is that they be XML structures. Even if there is only one piece of additional information supplied, it must be within a namespaced XML element. This is in order to ensure that servers can distinguish a field from one profile from another.
<extraRequestData> <theo:onSearchFail xmlns:theo="...">scan</theo:onSearchFail> </extraRequestData>
<extraResponseData> <rob:relevancyAlgorithm>CORI</rob:relevancyAlgorithm> </extraResponseData>
Apart from extraRequestData and extraResponseData, there are two further locations in which an extra data field can occur. These are in each record field in a searchRetrieveResponse and in each term field of a scanResponse message. Each of these contain profiled information about the record or term. This data can include metadata but is not limited to this. extraRecordData might include a field with the relevance associated with the record in a relevance ranked search, whereas extraTermData might include a link to the term within a thesaurus.
<extraRecordData> <rel:rank xmlns:rel="...">0.965</rel:rank> </extraRecordData>