Extra Data / Extensions
List of Registered Extensions
Messages in all of the operations, both in the request and in the response, have a field in which additional information may be provided. This is a built in extension mechanism where 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 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.
Rules and Semantics
(In this example 'info-4' identifies the namespace; see next paragraph.). Note that this convention does not guarantee uniqueness since (in contrast to SRW - see SRW Parameter below.) the parameter name will not include a URI. The extension owner should try to make the name as unique as possible.
If the namespace is identified by an 'info:srw' URI (and note that there is no such requirement, the namespace may be identified by a URI of a different scheme, for example 'http'), then a convention that may be used (as in the example above) is to name the parameter "x-info-<nnn>-<element name>" where <nnn> is the 'srw:info' authority string. This convention (suggested but not required) should guarantee uniqueness. It is strongly suggested that an extension name never be assigned with this form except by the proper authority for the given 'info' namespace.
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.
For SRW, The extra data fields is an XML structure. 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. Examples:
Extra data fields are identified by the root XML element qualified by the supplied namespace. In the above examples, for the extra request data the extension's identifier is 'onSearchFail' from namespace info:srw/extension/4/searchExtensions. The extra response data has identifier 'relevancyAlgorithm' from namespace info:srw/extension/2/relevancy. Below there is another example, where the extension's identifier is 'rank', also from the latter namespace.
Extra Data Example
For an example of how to create an extension, see the Record Schema Negotiation Extension whose purpose is to allow the client to propose multiple record schemas that it will accept in response and let the server select one, rather than the client giving the server an ultimatum as to which record schema to return. This extension modifies the base semantics of the protocol, as the record schema URI in the response might not be the one in the recordSchema parameter of the request.
Record, Term and Query Extensions
In addition to extra information being included at the top level of the response, there are three further elements in which information can be returned.
extraRecordData example (highlighted in orange):
And in addition "extra data" can occur within the term element for any term in a scanResponse message containing profiled information about the term. This data can include (but is not limited to) metadata about the term. For example, extraTermData might include a link to the term within a thesaurus.
March 31, 2016