ISO ILL Protocol Standards

What's New
Standards
Register
Implementations
Testing ILL Protocol Implementations
Reading
ASN.1 Index

Home
Site Index

In this Document:

  • Intro to ILL Application
    Standards
  • ISO 10160
    Service Definition
  • ISO 10161-1
    Protocol Specs
  • ISO 10161-2
    PICS Proforma
  • Where to Purchase
  • ISO TC46/SC4/WG4
  • Maintenance
    Agency Procedures
  • Profiles
  • Clarifications
  • Review
    For More Information,
    contact
    the ILL Application Standards
    Maintenance Agency,
    Library and Archives Canada

    ill_asma
    @lac-bac.gc.ca

    Last Update:
    2002/01/08



  • ISO ILL Protocol Standards
    Interlibrary Loan Application Standards Maintenance Agency


    ISO 10160/10161-1 Review White Papers

    Undo Functionality

    Discussion Group members:
    • Randy Menakes (Group Leader)
    • Kerry Blinco
    • Ed Davidson
    • Lyse Pérusse

    The concept of "undo" in the ISO 10160/10161 implies undoing or reversing a change in the state of an ILL-transaction. Version 2 of ISO 10160/10161 does not allow for the undoing of most state transitions. There are a few situations when a transition will move from state A to state B, and then back to state A. For example, a transaction on the Responder side can move from PENDING to CONDITIONAL and back to PENDING (upon receipt of a C-REP+). But in general, state transition is one-directional. The state tables make no allowance for return to a prior state because an operator error was made, or because of an unanticipated occurrence, like the discovery of material that had been declared LOST in Protocol terms.

    The ILL Protocol Implementors Group believes that the next version of the Protocol should investigate whether allowance might be made for undoing state transitions. To discuss this, we need to consider two different situations:

    1. The undoing of a state transaction when the request is now in a terminal state.
    2. The undoing of a state transaction when the request is now in a non-terminal state.

    Terminal State considerations

    Several factors make it impossible to back a transaction out of a terminal state. Once an APDU from a Responder moves the transaction into a terminal state, the Responder can no longer predict behavior on the Requester side. Consider the following example:

    1. Responder responds to an ILL-Request with an ILL-Answer/Unfilled
    2. Responder realizes that the message should have been ILL-Answer/Will Supply

    The Responder may wish to undo the results of the receipt of the ILL-Answer/Unfilled on the Requesting side, but the Transaction has already moved to a terminal state of NOT SUPPLIED. The Requester application may have already sent a (referral) request for the same item to another provider. Furthermore, the Protocol states that a request in a terminal state may be deleted or otherwise made inaccessible to the peer. When this occurs, the request is no longer available for undoing.

    Terminal states for the requester are:

    • NOT-SUPPLIED
    • CANCELLED
    • RECEIVED (non-returnables)
    • RETURNED
    • LOST

    Terminal states for the responder are:

    • NOT-SUPPLIED
    • CANCELLED
    • FORWARD
    • SHIPPED (non-returnables)
    • CHECKED-IN
    • LOST

    Terminal states for the intermediary are:

    • NOT-SUPPLIED
    • CANCELLED
    • FORWARD
    • SHIPPED

    Since one requirement of a new version of the Protocol is that it be backward compatible, this aspect of terminal state behavior seems inviolable. The only 'workaround' for these is probably to devise additional states (and corresponding APDUs) that would represent non-terminal versions of these states. LOST seems a likely candidate for this treatment, with the definition of a new, non-terminal state such as 'APPEARS LOST'. This state would be 'recoverable'. For example, the state tables would permit receipt of a Checked-in APDU if the item shows up at the Responder side. Each terminal state should be examined to determine whether a parallel, non-terminal state should be defined.

    Non-Terminal State considerations

    It is more likely that the Protocol will be resilient to reversal of state transitions from non-terminal states. Changes in this area would allow undoing of changes caused by human error. Examples include:
    • Sending a Shipped APDU for the wrong item (returnables only)
    • Sending a Received APDU for the wrong item (returnables only)
    • Sending a Recall APDU by mistake
    • Sending an Overdue APDU by mistake

    Although support for undoing these non-terminal states may be feasible, it's likely that the already complex state tables will be made considerably more complex.

    Forwarding and Intermediary considerations

    To date, the IPIG has declared the Forward Service and most Intermediary behavior out of scope. If the Group chooses to investigate adding 'Undo' functionality to a new version of the Protocol, it will have to take Forward Service and corresponding Intermediary behavior into account, since it will undoubtedly prove to be the most complex impediment to expanding the Protocol to permit reversal of state transition.

          Top of page


    copyright © 1998
    Interlibrary Loan Application Standards Maintenance Agency