NISO Circulation Interchange Protocol
  • Home
  • NCIP News
  • About NCIP
    • The Protocol
    • Extensibility
    • Implementer Profiles
  • About NCIP Standing Committee
    • Meeting Minutes>
      • 2014
      • 2013
      • 2012
      • 2011
      • 2010
      • 2009
      • 2008
      • 2007
      • 2006
      • 2005
      • 2004
      • 2003
      • 2002
    • Members
  • Documentation
    • Introduction to NCIP
    • The Standard
  • Links and Resources
    • Related Standards and Initiatives
    • XML Processing Tools and Utilities
    • Presentations and Publications

September 8-9, 2010 (In Person Meeting)

NCIP Standing Committee
Minutes - In-person Meeting
September 2010
Present
Voting Members
Susan Campbell - College Center for Library Automation
Rob Walsh - EnvisionWare (NCIP Maintenance Agency)
Mike Dicus - Ex Libris
Eric Leckbee - Innovative Interfactes
John Bodfish - OCLC
Tony OʼBrien - OCLC
Robert Gray - Polaris Library Systems
Kevin Stewart - Relais International
Gail Wanner - SirsiDynix (Chair)
DJ Miller - The Library Corporation
Observers
Karen Wetzel - NISO
Collete Mak - Notre Dame University
Minutes prepared and submitted by:
Rob Walsh, EnvisionWare / NCIP Maintenance Agency
Editorʼs Note: As part of this meeting, Wetzel reminded the group that NISOʼs official 
name for it is the NCIP Standing Committee. Previously, the group referred to itself as 
the NCIP Implementers Group. References in these minutes to the group will be the 
NCIP Standing Committee.
Page 1 of 30Table of Contents
Welcome and Introductions 4
Agenda Review 4
Implementer Updates 4
Other Standards News 5
Review Version 2 Changes 5
Review Items previous marked for further study 6
Review Schema Changes Resulting From Items Reviewed at April 
2010 Meeting 8
Future Version 2.x Changes 10
Performing Item Lookups Using Bibliographic Id 10
Identifying Deprecated Services 11
Provide Displayable Text for Enumerate Types 12
Break Out Groups to Review Changes Made to Section 5 12
Continuous Maintenance Procedures Changes 13
Overview of NCIP Forum (WebEx - Presented by John Barr, Polaris 
Library Systems) 13
NCIP Implementer Registry 14
Next In Person Meeting 15
2011 Call Schedule 15
NCIP as a RESTful Web Service 15
Break-Out Group Work on Documentation 16
Review Action Items 16
Page 2 of 30Adjourn 17
Appendix A - NCIP Implementer Registry Handout 18
Appendix B - Email Draft Describing NCIP as RESTful 28
Appendix C - Action Items 29
Page 3 of 30Wednesday, September 8, 2010
Welcome and Introductions
Wanner called the meeting to order and asked Dicus to provide a logistical overview of 
the facilities. Each person in attendance briefly introduced him- or herself.
Agenda Review
Wanner led a review of the agenda and asked if anyone had any changes to suggest. 
She reminded the group, too, that some people not present have planned to join the 
discussion on some topics by telephone, and we need to mindful of the schedule to 
ensure those topics start at the designated times.
Implementer Updates
Wanner asked if anyone had implementer updates to share. 
Leckbee reported that Innovative Interfaces is testing in a consortium in Michigan with 
Polaris. They are working to convert functionality currently using an implementation 
based on Direct Consortial Borrowing (DCB) to NCIP by eliminating some request 
messages, primarily with respect to user authentication. Innovative is nearly finished 
implementing messages to exchange with Relais International for PALCI, but they 
continue to work on the internal implementations behind the message exchanges.
Miller reported that TLC Library.Solution is working in Maryland with SirsiDynix. Two 
libraries are in final testing, and no failures have yet been identified. TLC is preparing to 
move all libraries that are part of this project to final system testing. Their next project 
will be with Melcat. Library.Solution is working also with Auto-Graphics in Louisiana. 
TLC CARL is working in Northbay. All work is with NCIP Version 1.
Gray reported that Polaris is working in Maryland with SirsiDynix. They, too, will be 
working on Melcat.
OʼBrien reported that OCLC WorldCat Navigator has an NCIP implementation, originally 
using Version 1. OCLC is committed to Version 2 and is beginning to develop a toolkit. 
Bodfish added that the code being written for Version 2 will be donated to the eXtensible 
Catalog (XCO) project and will be available under MIT license. Anyone interested in 
using the toolkit should contact XCO and get involved in the project. The toolkit 
supports the use of extensions, but none are presently implemented.
Page 4 of 30Other Standards News
Wanner asked if anyone had news from other related standards to share.
Wetzel reported that the Institutional Identifier (I2) working group has published a draft 
for feedback. They are working on how to better integrate with ISNI (International 
Standard Name Identifier). Their biggest issues are how to manage the data, how to 
maintain registries, and how to avoid conflict with existing identifiers (OCLC, ISIL, etc.).
Walsh reported that he recently assumed a co-chair role with the Discovery to Delivery 
Topic Committee. This position was held previously by OʼBrien.
Dicus asked if anyone had any updates regarding SIP 3.0. Walsh indicated that little 
mention has been made in the community outside of a reference made as part of the 
Massachusetts state-wide sorter project. Dicus indicated a comment made in the UK 
suggested that NCIP was dying and SIP 3.0 would be the next standard. Bodfish has 
heard similar comments. However, no one is aware of any definition or specification for 
SIP 3.0, so it is easy for it to be the “next best thing.” The group indicated that it will be 
interesting to see how 3M manages to achieve some of the goals theyʼve set for SIP 
3.0. OʼBrien suggested that, as a committee, we need to think about what our next 
steps will be if SIP 3.0 is introduced and begins to gain traction in the industry. We need 
to attempt to maintain contact with 3M to stay abreast of any developments.
Stewart commented that one of the biggest barriers to NCIP continues to be price. 
When vendors charge more for NCIP than SIP, customers are reluctant to pursue NCIP.
Wetzel indicated that we should continue to look for Version 2 success stories that can 
be highlighted and published to show the community that NCIP is working.
Review Version 2 Changes
Walsh reviewed changes being made in Part 1 and Part 2 of the NCIP Standard. The 
group discussed ways to simplify Section 5 in Part 1. Campbell expressed concerns 
over the tedious manual efforts associated with keeping the schema and the Standard 
in sync. She suggested that there should be some way, via an XSL stylesheet 
transformation for example, to automate the generation of Sections 5 (and 6) and 
reduce both the amount of work and the likelihood of additional errors. Bodfish said that 
there are some rules and semantics described in the Standard that cannot be 
adequately represented in the schema. He used the “if requested” model as an 
example.
Page 5 of 30Review Items previous marked for further study
Walsh reviewed three items that had been accepted for further study at the April 2010 
meeting.
Number: 2010-01-0010
Type: Defect
Subject: User Id is allowed both inside and outside of User Optional 
Fields; however, Item Id is not allowed inside Item Optional Fields.
Description: Need to determine which is “correct” and ensure that both 
are handled consistently.
Discussion (Apr. 2010): User Id can be used both as an identifier and as data. When 
used outside of User Optional Fields, it is a key. When used inside, it is simply data.
Decision (Apr. 2010): Accept for further study. Attempt to find concrete use cases 
that require Item Id to be used outside of Item Optional Fields.
Decision (Sept. 2010): Reject. The group was unable to identify a compelling use 
case to justify this change.
Number: 2010-01-0017
Type: Enhancement
Submitted By: OCLC
Submitted Date: During Version 2 balloting
Subject: NCIP is too cautious with respect to element repeatability.
Description: Recent implementation experience has shown that NCIP 
remains too cautious in the design of its data structures, specifically in the area of 
element repeatability. The Standard allows for tightening of rules via application profiles 
(e.g., marking an optional element mandatory), but it does not permit loosening of rules 
as would be the case if a non-repeatable element were allowed to repeat. If more 
elements are allowed to repeat it will also be necessary to specify the semantics. In 
some cases, it may be obvious how multiple or repeated elements are to be handled. 
But where the element is part of a key (e.g., Request Itemʼs Bibliographic and Item Ids), 
perhaps the semantics are that the initiator thinks any of them is valid, and the 
responder gets to choose. In these cases the responder ought to return the key chosen 
in the response.
Discussion (Apr. 2010): OʼBrien indicated that this seems to require open discussion 
within the group. It may be quite useful, but it may lead to chaotic and ambiguous 
implementations. Wanner explained that she could see making something like ISBN 
repeatable since many bibliographic records contain multiple ISBN numbers. Two 
disparate systems may not have identical bibliographic records. Repeating ISBNs, 
then, would seem to make sense. Jackson asked if we would also allow elements like 
title and author to repeat so that we could send different titles and different authors. 
Gray indicated that would not be relevant since we cannot search on title and author. 
Walsh noted, though, that the same example might be valid with ISBNs where two 
ISBNs do not represent the same work. That could lead to a confusing implementation. 
OʼBrien explained that the request is to make every element repeatable and to restrict 
Page 6 of 30them where necessary through profiles. Jackson asked what problem the proposal is 
trying to solve. OʼBrien said that the problem is philosophical rather than practical. He 
presented an example using Accept Item. It contains User Id. Repeating that might 
prove to be problematic. Jackson, however, said it could represent a book club. 
Stewart asked what it would mean to repeat a Pickup Location. The group 
acknowledged that would be a problem Gray indicated that the excessive repeatability 
might significantly increase the overall bulk of the messages. A Check In message with 
many items could get pretty big. Walsh observed that if one plan to execute the same 
number of check ins with separate messages, the aggregate would probably be less. 
Gray said that the response would likely be slower, however.
Decision (Apr. 2010): Accept for further study. Attempt to find use cases for how it 
might be used effectively and provide examples to the submitter showing potential 
problems.
Decision (Sept. 2010): Reject. The group was unable to identify a compelling use 
case to justify this change.
Number: 2010-01-0021
Type: Enhancement
Submitted By: Brent Jensen ([email protected])
Organization: SirsiDynix
Submitted Date: During Version 2 balloting
Subject: Add “transaction agency” or “transaction location” to Accept 
Item message.
Description: Add “transaction agency” or “transaction location” to Accept 
Item message.
Discussion (Apr. 2010): Wanner explained that Accept Item needs a third agency to 
represent the pick up location. There may even be a need for a fourth agency 
representing where the lending agency needs to send the item in order to get it into the 
borrowing system. Jackson asked if that is simply a function of the borrowing system. 
Wanner asked how the borrowing system knows where the user wants to pick up the 
item. Stewart noted that Version 2 has Pickup Location within the Accept Item 
Response.
Decision (Apr. 2010): Accept for further study. Ask Jensen whether Pickup 
Location within Accept Item Response meets his needs or if there are additional use 
cases.
Decision (Sept. 2010): Reject. The group was unable to identify a compelling use 
case to justify this change. Further, it was noted that Accept Item Response permits the 
use of Pickup Location in Version 2.
Page 7 of 30Review Schema Changes Resulting From Items 
Reviewed at April 2010 Meeting
OʼBrien showed two specific schema changes that resulted from change requests 
accepted at the April 2010 meeting. 
Number: 2010-01-0015
Type: Enhancement
Submitted By: OCLC
Submitted Date: During Version 2 balloting
Subject: Bibliographic Record Id is not repeatable in Bibliographic 
Description of Accept Item.
Description: Bibliographic Record Id is not repeatable in Bibliographic 
Description of Accept Item. It should be possible, for example, for an initiator to send 
Accept Item using both an OCLC number and an LCCN number.
Discussion (Apr. 2010): Jackson clarified that the requested change should be 
generic with respect to the types of ids allowed and not limited to OCLC and LCCN. 
Gray asked what the responder is accepting. Is it one item with two ids, or is it two 
separate items. OʼBrien explained that, when one is creating a temporary record, one 
may need multiple ids to represent a single item. “It seems like a fairly non-offensive 
change that would be generally useful,” he said. Wanner added that it is primarily a 
resource sharing issue. The lending organization may use one id, but the borrowing 
organization may use a different one. The common record, then, needs both. Gray 
asked if this would make Bibliographic Record Id repeatable everywhere it is used. 
OʼBrien indicated that the field is used only to carry information, never to identify an 
item, so allowing it repeat should not cause any problems.
Decision (Apr. 2010): Accept without modification. Change the schema to make 
Bibliographic Record Id repeatable within Bibliographic Description. Then update the 
Standard document to match the changed schema.
Page 8 of 30Number: 2010-01-0016
Type: Enhancement
Submitted By: OCLC
Submitted Date: During Version 2 balloting
Subject: Request Item does not allow a combination of Bibliographic 
Record Id and Item Id.
Description: Request Item does not allow a combination of Bibliographic 
Record Id and Item Id, and it does not allow either to be repeated. An initiator should be 
able to send both, and it should be possible to send more than one of each.
Discussion (Apr. 2010): OʼBrien explained that today one must choose to send either 
an Item Id or a Bibliographic Id but not both. This proposal would allow an initiator to 
send either or both. Gray asked if that meant the request would be for a specific item or 
any item that matches the Bibliographic Id. OʼBrien said that he did not think that was 
meant to be the case. It was meant to provide extra information. Wanner asked if it 
was extra or alternative information. Gray said that his understanding is that an Item Id 
always represents a single item. A Bibliographic Id would mean any item that matches 
the given criteria. Stewart noted that the proposal also includes a request that each be 
made repeatable. OʼBrien suggested that we need more information on why this 
change was requested so that we donʼt risk an implementation that is ambiguous.
Decision (Apr. 2010): Accept for further study. Attempt to find a use case that 
demonstrates how multiple and repeatable Item Ids and Bibliographic Ids might be 
used. However, through additional discussion, this decision was changed to “accept 
without modification.”
Bodfish explained that, at least initially and with respect to both changes, the context 
should be understood to mean a transaction on a single item identified by any of the ids 
supplied in the elements that have now been made repeatable. This distinction should 
be captured in the Standard, possibly in the Data Dictionary (Section 6) and/or in 
Section 5. As it stands, the response message is able to supply only a single Request 
Id (or Item Id in the case of Accept Item).
It was noted that the new version (deemed 2.01) is backwards compatible with the 
original Version 2 (2.0) with respect to an initiator at Version 2. However, an initiator at 
Version 2.01 cannot communicate with a responder at Version 2.0. This should be 
clarified in the version notes in the Standard.
Page 9 of 30Future Version 2.x Changes
Performing Item Lookups Using Bibliographic Id
Bodfish described a scenario where another future change may be necessary. The 
eXtensible Catalog (XC) is developing a discovery interface, a replacement for ILSspecific OPACs to augment and extend functionality. The basic process is to extract 
bibliographic information from the ILS, index it, and, using Drupal, build a patron 
interface. The next step is to add empowerment features for the patrons - the ability to 
place holds, check out, etc. NCIP becomes more relevant in this final stage. What 
theyʼve extracted from the ILS are bibliographic records, and what they are displaying to 
the patrons is bibliographic information. Their are additional data that could be 
displayed in the form of metadata about each item. However, NCIP does not permit 
lookups by bibliographic id. If that were added, we would have to address the issue of a 
response including multiple items rather than only a single entity since a bibliographic id 
may not represent a unique holding. XC added a custom message to address this in 
their Version 1 implementation. In Version 2, they can use an extension. They have 
drafted a proposal to put a bibliographic id in a lookup item request and allow the 
response to include a set of items. 
Walsh said on the surface it would not seem to introduce too many issues, at least in a 
lookup. Bodfish noted, though, that some requests might generate many items and the 
size of the response might be unwieldy. OʼBrien showed how the hypothetical change 
would not be technically complex in the schema. Gray suggested that it might be best if 
it were implemented with a new message because it could be implemented in the most 
appropriate way without any preconceived restrictions. Wanner asked if there is a need 
to expand the Standard this significantly, or if this is an isolated change where we could 
live with fitting it into the existing structure. Bodfish indicated that the big issue is the 
repetition of the bibliographic information that would be expected to be the same for 
each item in the set.
Another approach might be to make the subelements within NCIPMessage repeatable. 
That still may not address the problem of repeating the bibliographic data in each 
message. It may work in some contexts to assume that all members of the set share 
the same data, but in other contexts, it would be impossible to determine which are 
meant to be shared and which simply do not have bibliographic data.
OʼBrien suggested that new messages give us more opportunity to properly express the 
intent and the semantics for the exchange.
Walsh asked if the discussion would be different if we considered what happens if we 
expand the scope to include transaction oriented messages rather than just lookup 
messages. He said he might be willing to support simply changing the current structure 
if we limit the scope to only meeting immediate needs. However, if we consider the 
impact of potential future needs, we might be better served by adding new messages.
Page 10 of 30OʼBrien expressed concern over adding new messages since we have spent much time 
and energy trying to simplify. Wanner, however, indicated that clarity in the resulting 
messages should be considered.
Campbell asked why the Ext element is not appropriate to this change. OʼBrien 
indicated that it would be, but that we should consider how useful Ext implementations 
can be later incorporated into the Standard.
Gray said he thinks looking up an item by bibliographic id is conceptually different than 
lookup up an item by item id. A lookup by bibliographic id should carry a bibliographic 
payload, not an item payload. Bodfish agreed, noting that a Lookup Item Response that 
could be used for either type of request might become very confusing.
Bodfish added that, while this request comes from XC, it is fairly common among those 
working with ILS discovery products. He agreed to take the XC proposal and attempt to 
produce a schema structure to support it. His approach is likely to center around adding 
a new message. He invited others who may prefer making Lookup Item Response 
repeatable or overloading Lookup Item Response to handle both single and multiple 
items to draft their own proposals.
Identifying Deprecated Services
Wanner said that she would like to undertake a project to review existing services in an 
attempt to determine if any are unused and could be deprecated. OʼBrien suggested 
that we could do this here by going very quickly through the list to see if any are 
consensus targets for elimination. Campbell suggested that she could add a survey 
page to the Implementer Registry to allow implementers to provide feedback about each 
message: Important, Not Important, etc.
The group quickly reviewed each service and identified the following candidates for 
deprecation:
Agency Created
Agency Updated
Circulation Status Change Reported
Circulation Status Updated
Create Agency
Item Created
Item Recall Canceled
Item Recalled
Item Request Updated
Report Circulation Status Change
Send User Notice
Update Agency
Update Circulation Status
Page 11 of 30User Created
User Fiscal Transaction Created
User Notice Sent
User Updated
The group acknowledged that the results of this impromptu survey are non-binding and 
simply represent a “gut-feel” about which services may no longer be useful. Wanner 
agreed to draft a proposal to deprecate these (or a subset of these) services.
Provide Displayable Text for Enumerate Types
Bodfish described another item of interest for the XC. They would like to be able to 
display the ILS-specific wording for enumerated types such as circulation status.
Break Out Groups to Review Changes Made to 
Section 5
The group split into small groups to review the changes made to Section 5 of Part 1 to 
ensure they agree with the schema. It then reviewed as a large group the various 
findings. The group noted a discrepancy in Update Request Item Response where 
Required Item User Restriction Type is missing (as compared to Request Item and 
Renew Item). It was decided this was an oversight and should be corrected. OʼBrien 
made the change to the schema.
The group also reviewed Request Scope Type as being optional in Cancel Request 
Item. The thought was that it was required in Update Request Item; however, it appears 
that it is not required there. Therefore, no change is necessary.
Some discussion was held around using alphabetical or schema order for the 
subelements listed in each message described in Section 5. The group agreed to add a 
sentence to 5.2 to explain that the table is in alphabetical order and serves as an index 
to the rest of Section 5, but that the data elements listed in each message are in 
schema order.
The other minor typographical errors were reported to Walsh, and he agreed to make 
the appropriate corrections to the document.
Page 12 of 30Continuous Maintenance Procedures Changes
Wanner asked if anyone felt a need to propose any changes to our Continuous 
Maintenance procedures. Walsh reported that the delays that caused us to miss the 
initial revision deadline after the April 2010 meeting were largely logistical and due to 
insufficient infrastructure. He indicated that he is now comfortable with the timelines 
associated with each revision and feels confident that we will be able to publish future 
revisions in accordance with the procedures.
Wanner asked if anyone has concerns about the twice-per-year revision schedule. 
Various views were presented. On the one hand, it may be burdensome on responders 
and customers. On the other, it provides the ability to respond to needs identified in the 
community. No one expressed a strong opinion, and the group decided to retain the 
ability to release twice-per-year.
Wanner indicated a need to have a designated back up for schema changes. Stewart 
volunteered to serve as OʼBrienʼs back up.
Thursday, September 9, 2010
Overview of NCIP Forum (WebEx - Presented by John 
Barr, Polaris Library Systems)
Barr provided a demonstration of the NCIP forum (available at http://ncipnow.com). He 
explained that the site is very configurable, and we expect to see things change as we 
get feedback from the group about what is and would be useful. People may join the 
forum, but it is possible to view the content without being a member. Barr showed how 
one might start a discussion topic and post messages to the forum, and he 
demonstrated other features and functions available within the forum. Currently, 
registration is moderated and requires approval of the forum administrators (Barr and 
Dhaval Kotecha). However, Barr feels this may be temporary. The group discussed this 
topic and views on both sides were presented. Mak said that it should be open to 
encourage participation. OʼBrien cautioned that this might be overly trusting. If the 
forum gets the attention of some sort of automated bot, it may wreak enough havoc to 
force a fairly large clean up effort. However, he indicated that even unmoderated 
registration should help, and we might further limit unmoderated participation to a single 
forum. Bodfish said that we likely will not have sufficient information at registration to 
know whether a user should be banned. More likely, we would discover only later that a 
userʼs behavior warrants moderation or deactivation. Therefore, it would be better to 
allow people to register and post immediately (without specific activation) rather than 
force them to register and wait for activation, possibly losing the incentive to post. Barr 
agreed to change the registration policy so that new users do not have to be activated 
by an administrator. 
Page 13 of 30OʼBrien indicated that it might be beneficial to have some sub-forums accessible to 
anyone and others available only to certain users (members of the NCIP Standing 
Committee, for example). Barr agreed to create an Implementers Lounge forum that 
only members of the NCIP Standing Committee can join. OʼBrien expressed a 
preference that the private forum should not even be visible to those who cannot post to 
it.
Wanner said that a link to the forum should be added to the NCIP website. Walsh 
agreed to add the link. Wetzel asked if the forum has links to the NCIP and the NISO 
websites. Barr indicated that those links are available in the “About this forum” forum. 
OʼBrien added that useful posts (like the one with the links) can be “pinned” and locked 
so that they cannot be changed and they remain at the top of the forum in which they 
exist.
NCIP Implementer Registry
Campbell demonstrated the NCIP Implementer Registry she has been building in 
Drupal (http://ncip.dev3.webenabled.net). (See Appendix A for a copy of the handout 
she provided.) She showed how a user can search the site to determine what vendors 
support which NCIP messages and data elements. Most of the data in the site is 
fictitious at the moment (using names from mythology to make them easy to identify and 
remove later). She explained, too, how a user can download the data from the siteʼs 
database as an Excel spreadsheet. NCIP Implementers are able to create an account 
that will permit them to provide information about the use of NCIP in their products. An 
account manager (TBD but likely to be Wanner as the Chair or Walsh as the 
Maintenance Agency) will be responsible for approving and activating the account once 
the various information in the request is verified.
The group was overwhelmed with the work Campbell has done. Campbell 
acknowledged the assistance she received from Jackson and Wanner.
Wetzel asked for a timeline for moving the site from BETA to live. Walsh indicated that 
there are some technical issues that need to be resolved in order to migrate from the 
current hosting provider to the Maintenance Agencyʼs Drupal site. However, the 
responsibility for administering the site could be transferred earlier if the site can remain 
hosted with the current provider for now. The group agreed to aim for the end of 
October for bringing the site “on-line.” Group members agreed to send their company 
and product information to Campbell directly, and she will enter the information into the 
site. 
Page 14 of 30Next In Person Meeting
The group reviewed various dates in April 2010. Easter and Passover are the week of 
April 19-25. Computers in Libraries is March 21-23. The week of April 18 (with a 
meeting to be held April 20-21) seemed to be open for everyone. The group agreed 
tentatively to schedule a meeting for April 20-21 with a full day scheduled for 
Wednesday and a short day on Thursday (ending around 3 pm). NISO offered to host 
in Baltimore, and Relais International offered to host in Ottawa. Wanner agreed to add 
an agenda item for the next call to discuss again and make a decision.
2011 Call Schedule
Wanner asked if the group wants to retain the current call schedule. Presently, a 
monthly call is held the third Thursday of each month at 1 pm Eastern. No one 
expressed any objections. The group agreed that there is no need to hold the 
scheduled call on September 16. Wanner agreed to send a note to the list announcing 
that the call is cancelled. The next call will be October 21, 2010.
NCIP as a RESTful Web Service
Wanner asked the group to review Stewartʼs draft of a statement on whether NCIP is 
RESTful. (See Appendix B for a copy of the email sent by Stewart on May 10, 2010.) 
Bodfish expressed a concern over bullet point #4 (“Resources are accessed with a 
generic interface (e.g. HTTP, POST, GET”) and explained that NCIP uses POST. 
However, “good form” for HTTP and REST suggests that a message should be sent via 
an HTTP GET unless it performs some sort of update. For example, the Lookup 
Services should use GET since they do not cause any updates in the responding 
systems. 
Bodfish asked why this group feels the need to claim that NCIP is RESTful. Stewart 
indicated that the motivation is to make NCIP more accessible to some implementers, 
specifically the ILS-DI group. Bodfish added that some in the ILS-DI might challenge 
the claim that NCIP is RESTful, even with the provided justification, on the basis of a 
strict definition of REST.
Wanner asked if we continue to see value in having a statement like this. If so, she 
asked whether it should it be revised to minimize objections to it. Wanner suggested 
that we might post this topic to the forum to generate some discussion. Gray asked if 
the XC was relying on NCIP as a RESTful web service to obtain a grant. Bodfish 
explained that others in the ILS-DI, not just the XC, were interested in a RESTful web 
service (which would not be NCIP). However, in subsequent discussions, the group 
agreed to use some of the NCIP work from the XC for its purposes, and the 
“requirement” that the web service be RESTful became less significant. Therefore, it 
would seem that there is no longer a need to convince the ILS-DI that NCIP is RESTful.
Page 15 of 30Walsh asked what those in the ILS-DI who preferred REST were after in terms of 
benefits. Bodfish explained that the motivation was two-fold. First, many in the group 
are familiar with RESTful web services. Second, some wanted a simpler query syntax 
that did not involve parsing large XML data streams. Walsh added that the interest, 
then, was more in simplification than in REST itself. An NCIP that allowed for the XML 
payload to exist in a URI would be RESTful since it could be passed via HTTP GET, but 
it would not necessarily accomplish the objectives. Also, NCIP could be easily 
implemented as a RESTful web service where the service name and various data 
elements were expressed as URI attribute/value pairs. This would accomplish the 
groupʼs goals, but it would bifurcate the universe of implementations into those that use 
the traditional XML and those that use a simpler URI format.
Bodfish and OʼBrien suggested that a statement similar to: “Like RESTful web services, 
NCIP shares the following characteristics” and list those from Stewartʼs email except #4. 
OʼBrien further suggested that it could be voiced more aggressively by indicating that, 
while NCIP uses POST rather than GET, the Standard makes no presumption about 
whether the responding application generates side-effects (like logging or statistics 
gathering). Bodfish disagreed stating that REST implies that various objects need to be 
accessible via GET, and that the issue is not limited to whether side-effects are 
generated.
Bodfish volunteered to revise the statement to make it more appropriate, and Stewart 
and OʼBrien agreed to review Bodfishʼs draft. He plans to have something for the group 
to review by the October 21 conference call. He further agreed to involve people from 
the ILS-DI and/or the XC in order to ensure we meet their needs. Gray asked if their is 
still a need to make this statement. Various members of the group indicated that they 
see value in making the statement even if the ILS-DI and the XC are no longer 
concerned.
Break-Out Group Work on Documentation
The groups broke into two small working groups and reviewed draft documents on 
NCIP Core Messages and the RFP Writerʼs Guide. Both groups had many comments, 
so Wanner decided that each should send the comments to her to incorporate into the 
documents.
Review Action Items
The group reviewed the action items from the meeting. (See Appendix C.)
Page 16 of 30Adjourn
Wanner thanked Dicus and Ex Libris for hosting, thanked the group for attending, and 
adjourned the meeting.
Page 17 of 30Appendix A - NCIP Implementer Registry Handout
Page 18 of 30Page 19 of 30Page 20 of 30Page 21 of 30Page 22 of 30Page 23 of 30Page 24 of 30Page 25 of 30Page 26 of 30Page 27 of 30Appendix B - Email Draft Describing NCIP as RESTful
From: "Kevin Stewart" <[email protected]>
Subject: [NISO z3983maint] NCIP and RESTful web services
Date: May 10, 2010 11:34:49 AM EDT
To: <[email protected]>
1 Attachment, 3.2 KB
It was great to see everyone in Syracuse last week. During the meeting I was tasked with researching the requirements for RESTful web services
and if NCIP meets the requirements. 
First of all the basic structure of NCIP consists of sending an xml message via http or https and receiving an xml response which makes
NCIP a web service. In order to call NCIP a RESTful web service we need to look at the basic requirements.
1. REST is an architectural style, not a standard.
2. A RESTful web service must be completely stateless.
3. Should be based on a Client-Server architecture with a pull-based interaction style.
4. Resources are accessed with a generic interface (e.g. HTTP, POST, GET)
5. The service producers and consumers must agree on a schema that describes the data being exchanged.
6. There should be documentation describing how to process the data meaningfully.
The original definition of RESTful web services was based on the idea of a simple URL where something like
www.niso.org/RESTful/patrons could be used to ask for an xml response listing all patrons. This being said the concept of web services
has evolved over the past decade and I believe NCIP meets the basic requirements for RESTful web service status. I would like to
suggest an agenda item for the next meeting to discuss the possibility of adding text to the NCIP standard indicating that NCIP
messages are exchanged using RESTful web services.
I would appreciate comments from those more familiar with RESTful web services.
Kevin
Kevin G Stewart
Chief Technology Officer
[email protected]
Phone: 613-226-5571 x241 Toll Free (NA): 888-294-5244 x241
Skype: relais.kevin
http://www.relais-intl.com
Page 28 of 30Appendix C - Action Items
What Who When
Draft proposal to add a message similar 
to Lookup Item that accepts and returns 
information relating to more than one 
item, probably keyed on Bibliographic Id
Bodfish Before spring deadline for 
change requests
Remove activation requirement on new 
user registrations to the NCIP forum
Barr
Add an Implementers Only sub-forum to 
the NCIP forum and make it visible only to 
those who are allowed to access it
Barr, 
OʼBrien
Add a link from the NCIP website to the 
NCIP forum
Walsh Done
Add a link from the NISO website to the 
NCIP forum
Wetzel
Transition the NCIP Implementers 
Registry from BETA to live
Campbell, 
Walsh
End of October
Send company and product information 
about implementations to Campbell
Group End of September
Add discussion item to agenda for 
October conference call to decide on site 
for spring meeting
Wanner October 21, 2010
Post to the NCIP general interest list that 
September 16 conference call is canceled
Wanner Done (after the 
meeting but 
before Minutes 
were published)
Revise the statement showing how NCIP 
is similar to REST
Bodfish, 
Stewart, 
OʼBrien
October 21, 2010
Draft proposal to mark certain NCIP 
services as deprecated based on the 
results of our internal straw poll
Wanner
Page 29 of 30What Who When
Published the 2.01 schema to the NCIP 
Standing Committee
OʼBrien Done
Send working group comments on NCIP 
Core Messages draft documents to 
Wanner
Walsh
Send working group comments on RFP 
Guide draft document to Wanner
Leckbee Done (after the meeting 
but before Minutes were 
published)
Incorporate working group feedback into 
NCIP Core Messages and RFP Guide 
drafts
Wanner October 21, 2010
Page 30 of 30
Powered by Create your own unique website with customizable templates.