The following sections contain recommended interfaces for various ILS functions useful for discovery applications. Similar functions are grouped into categories for comprehensibility. As noted earlier, we specify both abstract functions (which do not specify a particular technology to use, but impose requirements on what any technology implementing them should do) and bindings (which specify particular technologies, and interface details specific to those technologies). For some bindings, we specify full details; for others, we simply note the possibility of creating such bindings. Our goal is to have at least one binding fully specified for each function, and for any ILS interface that implements this profile to fully and openly specify its function bindings.

Rationale, use cases, and general issues

Each category section opens with an explanation of the purpose of the category of functions, and discusses some of the possible use cases for these functions. These are intended to aid in understanding the rationale and use of the functions in the section.

Abstract function specifications

Each abstract function specification should include the following pieces of information.

The name of the abstract function

This is an abstract name used for reference in this specification. Bindings do not necessarily have to use this name, but it can simplify matters if they do.

Summary: A short synopsis of what the function does.

Parameters:

• name (type; optional or required): For each possible input to the function, we give its name, what kind of parameter it is, whether it is required or optional, and a short summary of its purpose.

Returns:

• A summary of the output of the function, if any.

Exceptional conditions:

• ExceptionName: For each applicable exceptional condition, we give an abstract name, and a summary of the conditions under which the exception may arise. Note that bindings do not have to actually model these as exceptions in their underlying protocol or programming language. (That would unnecessarily constrain our bindings, some of which do not include built-in exception mechanisms.) Nor do they have to use the exact names for the exceptions; like the function names, those are abstract. Alternative mechanisms for dealing with exceptions may include null or otherwise distinguished return values, auxiliary functions that signal the occurrence or possibility of exceptional cases, or even appropriate interface documentation. Bindings may also implement more specific exceptions than the ones defined here.

Side effects: If the function has any noticeable or lasting effect other than returning information, that should be noted here. If not, "None" should be stated here.

Rationale: A short summary of why the function is needed. This should be relatively short, if it appears at all; the rationale may already be covered in the general overview.

Notes:

Paragraphs under the Notes heading go into more detail about the required behavior of the function. They may also note some of the required data and services implied by the functions, give some examples of how the function might be implemented or used in practice, and give other hints for implementation and use.

Possible Bindings:

• Binding recommendation: We here name and briefly describe one or more ways in which this function could be bound to a particular technology. At least one of these bindings should have a specification, either here or in the general Binding details subsection below.

Binding details

We may have a general Binding details section after the abstract functions specification. It can be useful to distance the bindings specifications slightly from the function specifications, both because it helps avoid unnecessarily tying abstract functions to a particular technology, and because the same general binding details may be used for multiple functions in a given category.

(Next: Data aggregation)