We've had much discussion surrounding availability requests. The tentative
position at this point on what I put into the DLF proposal is for
GetAvailability to focus on a generic availability response and for a
possible GetServices function within the patron functionality section that
could take in an item identifier and patron identifier and return a list of
available services. I don't know off the top of my head if this GetServices
function could map to something already defined in NCIP or SIP2, so please
let us know if you think it does.

In terms of data returned, the required elements from a GetAvailability
function are going to be simple: the bibliographic record id, the item
identifier, a simple availability code (enum{ available, not available,
unknown}), date available (if not currently available), and a possibly
enumerated optional status message. Then there are some optional elements
we'd encourage being returned (location, call number, circulating flag,
number of holds).

I'm going to try to move on to the format of the response. For the DLF
proposal, we really have 2 options; piggy-back on an existing data standard
or create our own simple XML schema. While the simplicity of the second
option is appealing, it makes me a bit nervous. My particular concern is how
this availability information can also be integrated into the response for
Search, since there will likely be applications out there that may want to
know availability information along with other information about a title and
haven't pre-harvested the internal identifiers used for GetAvailability.
Since the DLF spec is proposing the use of either NCIP or ISO holdings to
include non-standardized item information (including availability) in the
Search response, I'm not sure how we'd bring in an external XML schema to
provide the availability information.

Does it seem like a reasonable solution to propose a simplified set of
elements from NCIP and/or ISO holdings for the possible responses for this
query? Some of the problems I see are that NCIP doesn't really support a
simple availability code (although the list of NCIP statuses could be mapped
to the 3 simple codes proposed), nor does it support including due date in
the LookupItemResponse element (although we could recommend that the
ItemDetails element be included as part of the response). ISO holdings
doesn't really include a place for a status message, although it could be
included in a generic fashion as a <sublocation> element or a  <note>
element. Both data formats should be able to handle the other data we're
defining for the response.

-emily