April 14 - 17, 2009 - NISO Circulation Interchange Protocol

April 14-17, 2009

NCIP Implementers Group
Minutes - In Person Meeting
April 14-17, 2009
Present:
3M - Paul Sevcik (Tuesday, April 14 only)
Auto-Graphics - Mary Jackson
EnvisionWare - Rob Walsh (NCIP Maintenance Agency)
Ex Libris - Mike Dicus
Innovative Interfaces - Lynne Branche Brown
NISO - Karen Wetzel
OCLC - Tony OʼBrien
Relais International - Kevin Stewart
SirsiDynix - Gail Wanner (Chair), Brent Jensen
Minutes prepared and submitted by:
Rob Walsh, EnvisionWare / NCIP Maintenance Agency
Tuesday, April 14
Agenda Review
Wanner called the meeting to order and thanked Innovative Interfaces for hosting. She
led group through a review of the proposed agenda. During the discussion around
marketing and education efforts, Wetzel indicated that NISO has been receiving
negative feedback relative to NCIP, mostly surrounding the lack of implementations.
She stressed that the group should focus on how to foster more implementations.
Wanner suggested that we might want to work to identify a core group of messages to
reduce the perception that NCIP is so large. “We use only about a dozen messages,”
she said. OʼBrien added that one of the main motivations behind version 2 was to
remove the perceived and the real barriers that were alleged to be preventing people
from implementing and collaborating. “We should really work to focus on fostering more
collaboration and implementation,” he said.
News and Updates
Wanner opened a discussion on general news and updates. She reported that the
Rethinking Resource Sharing group is planning an annual forum to be held in Dublin,
OH, in May. Although NCIP is not that groupʼs main focus, they support standards and
are particularly interested in NCIP. Wanner reported also that she has not yet received
any information relative to the LITA presentation that was submitted by members of this
group. She said that Susan Campbell at CCLA submitted another session, and she,
too, has not yet heard whether the session was accepted. Wetzel reported on an effort
from within NISO to pursue Single Sign On. A recent ballot appears to have garnered
1 of 29enough votes for a working group to be formulated. Wetzel indicated that the expected
outcome from those efforts is likely to be a recommended practice, not a new standard.
OʼBrien reported that Walsh recently accepted an invitation to join the Discovery To
Delivery Topic Committee. Walsh reported that he and Wanner had been working to
increase the amount of NCIP-related information published through NISO. These
efforts include articles in NISOʼs Information Standards Quarterly and news items in
NISOʼs monthly newsletter. Wetzel commented that the group should continue to do
this and more. “We really want to show people that this work is going on and that this is
an open venue,” she said. “We want people to know that the issues that have been
raised are being addressed.” Dicus reported that the eXtensible Catalog (XC) project
(http://code.google.com/p/xcnciptoolkit/) has published an NCIP toolkit. Walsh indicated
that a link to that project has been added to the Links and Resources section of the
NCIP website.
Concerns over Pricing
Stewart expressed frustration over the fact that some vendorsʼ pricing models for NCIP
serve as a barrier to entry for some of his customers. Wanner added that this group has
always stayed away from pricing and costs. She suggested, though, that there might be
something NISO could do to encourage people to make NCIP available at reasonable
costs. Stewart indicated that there is no real need to take any speciﬁc action. “We
simply need to make it clear that pricing issues may be damaging the standard,” he
said. OʼBrien asked if there are ways to mitigate those issues to reduce the impact of
concerns over pricing. Wetzel suggested that we should try to ﬁnd ways to point out
that it is possible to implement without incurring high costs. OʼBrien added that, given
the current economic climate, we need to do all that we can to make NCIP more
affordable. Wanner indicated that, by deﬁning a core set of message, we simplify the
process for implementing. Also, more work towards harmonization would reduce the
number of different approaches responders would need to support. “Each new proﬁle
often requires support for different messages or different handling for some messages,”
she said. “These things drive up the cost.” Jackson reported that Campbell has
reviewed several of the various DCB proﬁles, and she has a lot to offer on where they
differ and how they might be reconciled. Wanner encouraged the group to keep these
points in mind as we talk throughout this meeting. “If we ensure that they are part of our
discussions, then we might ﬁnd ways to address them,” she said. Jackson suggested
that there might be value in trying to identify messages that are rarely used and
eliminate them. OʼBrien cautioned that we might be able to deﬁne core proﬁles that
identify the must-have messages, but that we might not want to actually eliminate any.
“I am reluctant to remove really good messages, but I do think we can relegate them to
the background,” he said. Brown agreed that we should focus on the core set but leave
the others to demonstrate that there is more functionality available if it is needed.
Dicus, though, raised another point commonly heard from customers. “There is a belief
that, if a vendor supports the standard,” he said, “it should support all of the standard.
The core message set might create some confusion over what is supported.” Wanner
responded that if we can agree on a core and people implement that core, then we can
be clear about compliance.
2 of 29Review of NCIP IG Purpose, Structure, and Procedures
Wanner began a discussion of the purpose, structure, and procedures for the NCIP
Implementers Group as posted on the NCIP website.
* Forum for discussion of technical issues - the group agreed that this remains a valid
part of the purpose
* Advisory group to the Maintenance Agency - the group agreed that this remains a valid
part of the purpose
* Manage and approve application proﬁles
Wanner asked whether it is really part of the purpose of this group to approve
proﬁles. Brown said that, at previous meetings, we had agreed that the group
would simply publish the proﬁles. By virtue of them being published, they were
“approved.” Wanner suggested that we change the wording to reﬂect that we
collect and publish rather than approve. “Someone outside the group may infer
that we actually vote on them,” she said. Jackson asked if there is a distinction
between the original proﬁles (created as part of the initial version 1 efforts) and
those that have been created since. Walsh indicated that the older proﬁles have
been separated from the newer ones and placed into an archive on the website.
Jackson said that there may be a perception that the proﬁles with vendor
information are not seen as “approved” or “ofﬁcial” in the same way as the
originals. Walsh, though, asked whether the original proﬁles were really
hypothetical because they were created before any implementations existed.
Wetzel indicated that NISO is getting a lot of pressure to pull support for NCIP
due to issues associated with implementations. The proﬁles are confusing
because they imply that each vendor has its own implementation. “Thereʼs a bit
of reality in that,” Brown added. Wanner suggested that we could change the
way that we are posting the information. “We did, though,” she continued,
“create NCIP as a toolkit standard.” Wetzel asked if that perception is one we
want to continue.
Sevick asked about the impact of an approach that collects and publishes, but
without any approval or versioning. “How do libraries feel about long-term
support and compatibility,” he asked. Wetzel suggested that more information on
the website to explain with what systems and versions an application proﬁle is
intended to work might help to address this. Wanner recalled that, when the
DCB proﬁles were drafted, the four approaches were done as exercises. “They
are not a part of the standard,” she said. “They are just ideas for how it might be
used.” Jackson added, however, that people think of the proﬁles as part of the
standard because they are on the NCIP website. Wanner and Jackson agreed
that the C-ILL proﬁles may more accurately reﬂect how NCIP systems
3 of 29communicate, partly due to the fact that C-ILL had a ﬁrmer grounding than DCB
at the time when the proﬁles were written. Wanner suggested that there might be
value in continuing the efforts to harmonize DCB and C-ILL as they are done with
NCIP to see if they can use the same set of messages. Jackson said that
Campbell has been reviewing the proﬁles very carefully and is ﬁnding numerous
discrepancies. “Most are probably due to editorial sloppiness,” said Jackson.
“However, others who look at the proﬁles may have the same experiences.”
Jackson continued by suggesting that we add a note that the existing proﬁles
were written to support version 1 and may not work with version 2. Walsh asked
whether the note should be applied to all existing proﬁles or just those currently
residing in the archive. Wanner said that we should indicate that all of them were
written to support version 1, and she suggested that those in the archive should
have an extra note indicating that they are intended as examples and should not
be used. “That way,” she said, “people wonʼt view them as authoritative.”
Wetzel asked if the group is planning to update the more current proﬁles to be
compatible with version 2. Wanner suggested that our discussions around a core
set of messages will likely impact the existing proﬁles.
OʼBrien returned to the point of this groupʼs role as it relates to proﬁles. “It is a
responsibility of this group,” he said, “to review and make recommendations for
all existing proﬁles.” Brown suggested that we change the bullet point in the list
deﬁning the groupʼs purpose from “Manage and approve application proﬁles” to
“Collect and publish application proﬁles.” Sevcik reiterated a desire to make an
effort to incorporate some kind of versioning scheme.
* Accelerate the implementation of NCIP - the group agreed that this remains a valid
part of the purpose, possibly even the most signiﬁcant part
* Promote NCIP through educational activities - the group agreed that this remains a
valid part of the purpose and that it has been putting more efforts into this area
* Broaden the technical membership of the group
Wanner indicated that we have not done much of this lately. “We seem to have
lots of other priorities,” she said. Walsh suggested that we should make an effort
to consolidate the group and reach out to those who have been less active
before we expand. Jackson asked whether we should reach out to more
librarians. OʼBrien agreed that it has been valuable to have someone like
Campbell participating in the group. Wetzel added that people appreciate that
NISO represents both vendors and libraries. Wanner said that the economic
climate may make it difﬁcult to recruit more members. Oʼ Brien suggested that
we might need to review the mechanisms by which we meet in order to be more
cost conscious. Although we get more done when we meet face-to-face, he
indicated that we might be more effective in recruiting more members, especially
librarians, if we can ﬁnd more effective ways to meet remotely. Wanner asked if
4 of 29NISO is doing things in other arenas to compensate for difﬁculties holding inperson meetings. Wetzel said she was surprised that she had been able to
attend this meeting due to cuts in travel expenses. “This is one of the few groups
that continues to hold regular in person meetings. People are using more of the
on-line tools and working hard to communicate really clear ideas about what
needs to be accomplished” in order to make those virtual meetings more
effective. Wanner asked if others have had success with teleconferences.
OʼBrien said that the technology often gets in the way and that time often is
wasted trying to get the infrastructure established. Jackson said that, while she
has been part of effective sessions, they were not attempting to have the types of
discussions that we have when we meet. Wanner agreed that teleconferences
donʼt generally facilitate this type of discussion. Wetzel suggested that effective
teleconferences require more up-front planning. Stewart indicated that he has
had success with hybrid meetings where some people are local and others are
remote via webcam and speaker phone.
Wetzel suggested that there might be value in having a smaller, very focused
group and a larger, less active group. OʼBrien agreed that there are certain
discussions that relate well to the larger group and others, like showing the XML
schema, that need a smaller audience. He continued by reiterating that we need
to work to address the logistics of how we are going meet, in this climate, before
we can recruit effectively. Jackson added that we need to be able to provide
compelling content for people to want to take time from their schedules and
participate in the meetings. Walsh suggested that having a clear and fairly
narrow focus (and a looming deadline, added Wanner) was part of what made
the small group efforts effective last fall when we were working to ﬁnalize version
2.
Brown asked whether we had sufﬁciently answered the question of whether a
part of the groupʼs purpose is to broaden the technical membership. The group
agreed that the emphasis on technical may not be necessary. Wetzel suggested
that “Assure a balanced representation of interested parties” should be used
instead. Wanner indicated a preference to keep the current item and add the one
Wetzel suggested.
* Acquire feedback and requirements from end-users
Jackson suggested that we revisit this item at a later time. She felt that it is really
part of the prior discussion around membership and balance.
Wanner asked if anyone could think of other things that should be part of the purpose.
Jackson suggested that the current purpose does not address maintaining and revising
the standard. Walsh suggested that would come under “advise the Maintenance
Agency.” Wetzel added also that this notion may change after discussing whether to
move to continuous versus periodic review of the standard.
5 of 29Negative Feedback Received by NISO
OʼBrien asked Wetzel to elaborate on the various pressures NISO is facing relative to
NCIP. “The feedback weʼre hearing is ʻIt doesnʼt workʼ and NISO should not be
supporting it,” she answered. She indicated that at ALA mid-winter in January there was
talk about the pace of the standards process and how libraries donʼt know what to ask
for. Those are the reasons being given for why it doesnʼt work. “The feedback isnʼt
new,” she continued. “Itʼs things youʼve probably heard. This is why it is so important to
focus on PR - a make-over for NCIP, so to speak.” OʼBrien asked what the most
important target audience for efforts relative to restoring the image would be. Wetzel
indicated that it is difﬁcult to pick one, and that each member of this group needs to
work to promote their own implementations and develop them if they do not exist.
NCIP Implementers Group Membership Requirements
Jackson suggested that we should review and possibly revise our requirements for
participating in this group. Wetzel indicated that it is permissible under NISO to state
requirements like “if you miss two calls in a row you can be removed.” Brown
suggested that we establish membership requirements that conform to NISOʼs
guidelines. Wetzel presented the NISO Policies and Procedures guide, speciﬁcally
section 2.3, that governs committee membership (see http://www.niso.org/about/
documents/NISOprocedures2008ﬁnal.pdf). OʼBrien made a motion to approve the
NISO guidelines as they relate to deﬁning membership requirements for the NCIP
Implementers Group. Brown seconded the motion and the group raised no objections.
Binding Decisions at In Person Meetings
Wanner reminded the group that, in the past, weʼve opted not to make binding decisions
at in person meetings. Historically, weʼve posted recommendations to the list and
allowed for a two week review period before calling a formal vote. “Is that something we
want to change?” she asked. Jackson expressed her concerns and frustrations over
the usual lack of response from the list during the review period. “If people know
decisions will be made,” she said, “they may be more likely to attend.” Wetzel added
that the agenda is published beforehand, so people with a speciﬁc interest have a
chance to express their positions ahead of time if they will be unable to attend. Wanner
suggested that the group should formally deﬁne what constitutes a quorum for meetings
and votes.
Designated Contacts for Member Organizations
Jensen requested that it be possible to name both a primary and a second contact for
each organization. OʼBrien suggested that wording should be added to the members
list page on the website indicating that each organization receives one vote and may
name a primary and secondary contact. The ﬁrst name listed is the primary, and that
personʼs vote is considered authoritative for the organization in the event that both the
primary and the secondary contacts cast a vote. The primary contact may designate a
6 of 29temporary contact who may speak for (and vote on behalf of) the organization for a
speciﬁc time period or event.
Voting versus Non-Voting Membership
Walsh suggested that we may be changing the structure of the NCIP community to one
where there are those who are members of the Implementers Group (with voting
privileges) and those who are part of a general interest group. This might imply that we
no longer need voting and non-voting membership within the Implementers Group.
Wetzel asked whether there is a need for a third layer, some kind of technical subgroup. Wanner responded saying the the nature of the tasks probably will dictate the
technical level required, and she saw no need to explicitly differentiate.
Contacting Inactive Implementer Group Members
Wanner requested that the minutes reﬂect the decision to adopt the NISO guidelines for
membership in the Implementers Group. Further, she indicated that she and Wetzel will
contact current members who are presently inactive and inform them that they are being
removed from the group as they do not meet the new criteria. Those organizations will
have the option to re-join the group by agreeing to abide by the new requirements for
participation.
Review of NCIP Implementers Group Procedures
Wanner began a review of the NCIP Implementers Group procedures are posted on the
NCIP website.
* Consensus is golden - the group agreed that this remains a valid part of the
procedures
* One vote per member organization - the group agreed that this remains a valid part of
the procedures
* Organization must be an NCIP developer
Wanner indicated that weʼve never enforced this requirement. Jackson
recommended changing the item to read “Organization must be interested in the
development of the NCIP standard.” Wanner suggested actually removing this
item.
* Organization decides the member who votes - the group agreed to accept OʼBrienʼs
earlier proposal as the deﬁnition for how an organizationʼs vote is determined
* Attendees at the ﬁrst meeting are members - the group agreed to remove this item as
it is no longer relevant
7 of 29* Chair accepts membership applications or refers applications to the group - the group
agreed that this remains a valid part of the procedures
* Chair maintains membership list - the group agreed that this remains a valid part of the
procedures
* Chair is always a voting member - the group agreed to remove this item as, by
eliminating the notion of voting and non-voting membership, it is no longer relevant
* A member can propose a vote (must be seconded) - the group agreed that this
remains a valid part of the procedures
* Two-thirds of participants in vote count as a majority
Wanner indicated that the NISO guidelines call for only a simple majority.
Wetzel, though, said that the group is allowed to make its own decision for what
constitutes a majority. OʼBrien recalled that the choice of two-thirds was
intentional. Jackson asked whether “participants” means “those at the meeting”
or “those in the group”. Wanner returned to the idea of deﬁning a quorum.
OʼBrien suggested that two-thirds of the membership should constitute a quorum.
The group agreed and further deﬁned that this number is required to hold a vote.
50% of the membership plus 1 vote is required for a vote to pass. For example,
if there are 12 members, 8 constitute a quorum. 8 or more would need to vote
for the ballot to be considered binding, and 7 votes in favor would be required for
passage.
* Abstentions donʼt count either for or against - the group agreed that item this remains
a valid part of the procudures; further the group acknowledged the potential for
confusion as to how abstentions count relative to deﬁning a quorum
* All decisions, plus details of votes, must be recorded in meeting minutes - the group
agreed that this item remains valid as part of the procedures
* Conference calls follow the same rules
Wetzel asked whether we should add any wording to reﬂect other forms of
remote meetings. Wanner suggested that this item should be removed and that
the group should assume that all meetings follow the same rules.
* List discussions follow the same rules but have a duration, exceeding of which
amounts to abstention - the group agreed to revisit this item once a decision has been
made on whether to use the voting facilities available at the NISO website
* Chair is the only person who convenes meetings - the group agreed that this item
remains a valid part of the procedures
8 of 29* Chair is the only person who approves voting process - the group agreed to remove
this item since the voting process is sufﬁciently well-deﬁned elsewhere in these
procedures
* Chair decides if reconsideration of decisions is warranted - the group agreed to
remove this item and leave the decision to reconsider in the hands of the group and
subject to the other procedures (i.e., motion and second to reconsider the decision)
* Chair may designate a proxy - the group agreed that this item remains a valid part of
the procedures
* Chair reports success or failure of the vote - the group agreed that this item remains a
valid part of the procedures
* Default email vote duration is one week; Chair may reduce or extend this at own
discretion - the group agreed to revisit this item once a decision is made on how
electronic voting is to be managed
* Finalization of application proﬁles will follow the established voting process - the group
agreed that this item should be removed since the group does not approve application
proﬁles
Sevcik asked whether we should add any procedures deﬁning how the chair is selected.
Wetzel suggested also that we should specify the term of the chair. Wanner indicated
that, so far, the chair has served until he or she decides to step down. “Should there be
a term limit?” she asked. Sevcik asked whether the term should actually be limited or
whether there should simply be a periodic review or reafﬁrmation. OʼBrien indicated
that we should not require someone who is doing well and who wants to continue to
step down. Jensen suggested that we could allow the regular voting process (motion
with second) to initiate the process to replace the chair. Wanner suggested that, at the
very least, we should indicate that the chair is elected by the group. Jackson
recommended adding that the term is undeﬁned (or open-ended).
Continuous Versus Period Review
Wanner opened a discussion on whether the group should adopt a continuous review
process for the standard rather than persisting the current process that requires a
formal review every ﬁve years. Wetzel explained that ANSI provides for both
mechanisms. NCIP is currently governed by the rules that require it to be reafﬁrmed
once every ﬁve years. The scope of what can change between formal reviews is
limited. Any substantial changes require another formal ballot. The continuous review
process is starting to become more popular, probably due to the pace of advances in
technology. Z39.7 is currently the only NISO standard using the continuous review
process. With that group, comments are made regularly and a committee reviews them
every six months. The committee decides which to adopt and then informs the
membership of the changes. This does not require a formal vote before the full
9 of 29membership, but it does require more formal process for communication and decision
making. Wanner asked if the change interval has to be speciﬁed up-front. Wetzel
indicated that the interval must be speciﬁed, but no changes are required to be
published at each interval However, if no changes occur during the interval in which the
standard would have had to be reafﬁrmed under periodic review, the standard would
have to be formally reafﬁrmed with a ballot before the full membership. OʼBrien
observed that we have not yet made it through any four year period without a change.
Wetzel added that continuous review would allow for those changes to be made more
regularly. Jackson asked whether each published change receives a new number.
“How do we address issues associated with backwards compatibility?” Wetzel
explained that there is a lot of ﬂexibility inherent in the process, and handling for many
of those issues is not prescribed. “The group would need to deﬁne how those sorts of
issues are managed.” OʼBrien suggested that we can control versioning by requiring
each update to the schema to trigger a version number update to the schema itself.
Jackson asked how we communicate to the community the impact of, for example,
version 2.0 versus 2.01. OʼBrien indicated that, so far, weʼve broken backward
compatibility only once. “I recommend that we continue that practice,” he said. Jackson
expressed a concern over the perceptions associated with the frequency of change.
Wanner added that, with the advent of extensions, we are likely to see more changes
over time. “It would be better,” she said, “to see those changes become part of the
standard rather than have them implemented as vendor-speciﬁc extensions.” OʼBrien
indicated that was an intentional component of the extensions mechanism. “We wanted
useful extensions rolled into the standard,” he said. Jackson continued to explain that
her concerns relate to the potential for confusion over the compatibility of different
versions. OʼBrien suggested that if we do a good job of maintaining backward
compatibility, then two versus compliant with the same base version should be able to
interoperate. Jensen recommended adopting a practice of allowing ourselves to break
backward compatibility only in major versions. Wanner added that it is incumbent on
vendors to document and publish what versions they support. OʼBrien reminded the
group that we have this problem already in that we have two incompatible versions.
Jackson returned to the question of moving to continuous maintenance. “Is there
anything really harmful that might prevent us from going to continuous maintenance? It
sounds like we have everything to gain.” Wanner agreed that we do have a lot to gain,
but cautioned the group to be mindful of the responsibility associated with creating new
versions in less than four years. Walsh suggested that we donʼt have to publish new
versions that frequently, but we have the option to do so when we have the need.
Wetzel agreed that it puts the group in a position to act on things the community sees
useful. “It more closely reﬂects reality,” OʼBrien continued. “Weʼre doing this already
every time we update the schema.” Steward added that if we stick to the idea that only
major versions may break compatibility, and we agree not to publish new versions every
week, then we limit the risk that people will object to the changes. Sevcik reiterated that
the on-going maintenance may require a higher level of commitment. OʼBrien
suggested, though, that the changes could be implemented without additional face-toface meetings. Jackson added that we might encourage more adoption by being able
to make small changes more frequently. Wanner said that, from a PR perspective, this
10 of 29might be very beneﬁcial to us. “If we announce that we are going into a continuous
maintenance mode and really encourage feedback, then we may get some good input.”
Wanner asked whether the group was generally in favor of moving to continuous
maintenance. OʼBrien indicated that there appears to be consensus around the
principle, but weʼll need to deﬁne more of the details as we begin to prepare the
documentation necessary to make the change formally with ANSI. Walsh agreed to
work with Wetzel to review the required documentation and formulate a list of the
decisions that will need to be made. He will bring this information back to the group for
further discussion and a formal, ﬁnal decision.
Self-Service Needs
Wanner asked if any more discussion was necessary around needs speciﬁc to selfservice. Walsh explained that it might be better to give self-service implementers more
time to explore the changes introduced in version 2. “Iʼm not sure it would be fair to
harp on what else needs to be done,” he said, “until we have a chance to see what is
possible.” Sevick added that what is really needed are more implementations. He
agreed that there may be more work to be done, but a lot of functionality was added in
version 2. Wanner asked what needs to be done to get those additional
implementations. Walsh said that, historically, it has been difﬁcult to deﬁne a strong
business case. “Why do NCIP when thereʼs no beneﬁt beyond what can already be
done in SIP?” Version 2 adds some functionality to get more information with fewer
requests than with SIP, but is that the kind of enhancement that adds real value that
customers see as signiﬁcant? Other features, like being able to offer patron selfregistration and address veriﬁcation and update, do add real value, but there arenʼt
systems that provide those functions. Self-service implementers are at the mercy of the
ILS vendors to provide responders to do self-service with version 2. Walsh agreed to
work with (Sue) Boettcher at 3M to deﬁne a set of discrete workﬂows that are speciﬁc to
self-service.
Revisiting Application Proﬁles
Jackson suggested that the application proﬁles should be geared more towards
workﬂows and performing tasks than on exchanging messages. “Such proﬁles,” she
said, “allow us to begin to make lists of those vendors who implement the messages
necessary to perform useful tasks. This information may be in the current proﬁles, but it
is probably so buried that it isnʼt obvious.” Wanner agreed that we should again review
the application proﬁle template. The template should probably start with some
information about what the proﬁle will allow a user to do. Jackson added that the
proﬁles, originally, were intended for developers, not for users. Brown suggested that
we might need two documents. Wanner agreed that, at the least, there should be two
sections, one aimed at each audience. OʼBrien added that one should focus on the
raîson dʼetre - the high-level goal or objective - plus the technical detail.
11 of 29Possible Changes and Additions to Version 2
Wanner led a review of a list of items that had been compiled last fall during the efforts
to ﬁnalize version 2 for publication. Some of these items originated as comments
received during the balloting, and others were the result of work done to ensure the
various pieces of documentation associated with version 2 were consistent with one
another.
* Distinguish individual for institutional users - comment from Library of Congress
Wanner suggested that this might be dependent on how each individual ILS
implements borrowing. Jackson explained that the issue might be that it isnʼt
easy to pass the parent institution in the relevant messages. The group reviewed
the actual comments and decided that the request was for a way to loan
materials to an institution (i.e., a Congressional ofﬁce) rather than to an individual
user. Additional discussion suggested that another aspect of the request was to
perform tasks in batches (i.e., expiring all users associated with a Congressional
ofﬁce). The group concluded that NCIP already has sufﬁcient mechanisms for
identifying the relevant agencies and that the speciﬁcs of this request depend on
the actual implementation within the ILS. As a result, the group decided that no
action should be taken on this issue.
* Allowing patrons to be owned as part of larger organizations - comment from the
Library of Congress
The group concluded that this item was related to the previous one and again
decided that no action should be taken.
* Re-review the process for requesting optional information in Lookup messages
Jensen explained that, early in the version 2 discussions, we had wanted to have
only way of asking for optional information. However, version 2 still deﬁnes at
least two ways: the use of empty elements and the use of what in vesion 1 was a
scheme/value pair to request the desired information by name. OʼBrien
explained that some of the desired changes had to be removed from version 2
during the ﬁnal editing because the balloted documentation did not agree with the
schema. The changes necessary to make the standard match the schema were
deemed to be “signiﬁcant” and would have required us to reballot the standard.
Walsh asked whether the situation could be corrected now without break
backward compatibility. OʼBrien suggested that it might be possible to add a new
optional element that represents the preferred approach and then allow
implementers to choose which approach to use. In version 3, we could remove
the non-preferred mechanism. “As an initiator, this would not be a problem,” he
said. “However, as responders would have to implement both approaches.” The
group decided to defer any action on this item until we next have a reason to
12 of 29break backward compatibility since there is no real value in making the changes
now. They would actually introduce additional complexity in the short term.
* Add transaction agency or transaction location to Accept Item
Jensen explained that when an item is created while handling Accept Item, there
is no way to identify the physical location associated with the new item
(particularly when the transaction is being processed in a central facility).
OʼBrien indicated that version 2 contains Pickup Location as an element within
Accept Item. Brown also pointed out that there is a repeatable location element
that contains a Location Type which is just a string value. She suggested that
the example of p.57 on Part 1 be updated to include “Borrower” and “Lender” as
sample values.
* Determine whether user id, bibliographic id, and possible other id elements should
repeat in places where they are used - comment from OCLC
Jensen explained that a response should be allowed to include multiple
identiﬁers for the item if the item has more than one. OʼBrien indicated that
multiple ids might be problematic in a request since it could make the request
ambiguous, especially if the ids each resolved to a different entity. Jensen
agreed that repeatability might be valid only for responses. Brown asked if there
is a real market need for this functionality. Dicus read the original comment
which cited an example where a request might include both the ISBN and an
OCLC number. OʼBrien added that, as it relates to Accept Item, the request is
not being used as a lookup. The ids are purely descriptive. Dicus indicated that
a second part of the comment relates to using bibliographic id and item id in a
Request Item message. The standard currently requires the use of one or the
other. OʼBrien agreed that there might be valid uses for this, but that we might be
implying a particular workﬂow if we allow both ids in the request. “Does the order
in which the search is conducted matter, for example?” he asked. Wanner
agreed that there may be a good case for being able to repeat something like an
ISBN since records can have two ISBNs, a short and a long. In those cases, if
you canʼt send both ids, you may not be able to ﬁnd the item. Brown indicated
that, while not opposed to the change, we should be mindful that we may be
expanding the protocol from being speciﬁc to a single item to now being one of
many items. Jackson added that, in some cases, we donʼt know the speciﬁc item
anyway. Stewart asked if this is a place where we should recommend the use of
extensions. OʼBrien suggested that if we feel it is a valid change why should
require that it be implemented as an extension. “I do think, though,” he
continued, “that there may be cases where the nature of the message may be
different. Multiple ids in a request message may mean ʻrequest one ofʼ in some
cases and ʻrequest allʼ in another.” Jackson suggested that we could review
each case individually and decide whether the change makes sense in each
context. OʼBrien indicated that might be a large task. Jensen suggested that we
could wait for a valid use case implemented as an extension, then modify the
13 of 29standard to incorporate that speciﬁc use case. Stewart agreed that he felt that
was part of the intended purpose for extensions. Brown agreed also, stating that
it makes more sense to address things as they come up in actual use than it
does to make wholesale changes throughout the schema. Jackson
recommended that we should note that we are intentionally addressing two
speciﬁc cases and not reviewing the standard as a whole. The group agreed that
the following changes should be made to the schema:
* Allow Bibliographic Id and Item Id to be both repeatable and not mutually
exclusive in Request Item. At least one of the two must be present, but both
can be present and both can repeat.
* Allow Bibliographic Record Id to be repeatable in Bibliographic Description
within Accept Item
Wetzel cautioned that no changes should be made until a ﬁnal decision is
reached on the question of continuous maintenance and procedures are put into
place for publicizing proposed changes. “Under continuous maintenance,” she
said, “you have to provide forums for feedback.” The group brieﬂy discussed
how to allow changes to evolve through a series of drafts and conversations
without compromising the obligations of the continuous review process.
Ultimately, the group decided that informal and non-authoritative changes could
be made in order for the group to review and reﬁne them. Over time, these
changes would be collected and published in accordance with the procedures
that are to be deﬁned for continuous review. OʼBrien agreed to make the
changes to the schema as a draft and only for review purposes. Further, Walsh
agreed to draft a “Release Notes” document explaining the technical details and
the motivations behind the changes.
* Repeatable problem element
The group agreed that this represents a case where the schema and the
standard disagree. The schema represents what the group intended for version
2, but the standard was not properly updated before going to ballot. As a result,
the standard could not be changed during ﬁnal editing to be consistent with the
schema. Brown volunteered to review the protocol to determine the scope of the
changes necessary to make the standard agree with the schema. She was able
to complete the review before the meeting was adjourned, and she reported that
many elements as documented in the standard are not marked as repeatable in
places where they are repeatable in the schema. The documentation for these
elements needs to be updated in order for them to match the schema.
* Review use of User Id both inside and outside User Optional Fields
The group agreed that User Id is allowed to exist both inside and outside User
Optional Fields (within Lookup User) as a result of the version 2 change to
replace Visible User Id and Unique User Id with User Id. However, the group
14 of 29further agreed that the duplication does no harm and actually might serve a
useful purpose since the User Id within User Optional Fields is repeatable and
contains a User Id Type element.
* Review use of Item Id both inside and outside Item Optional Fields, primarily for
consistency with User Id and User Optional Fields
OʼBrien offered a use case where, during check in the system might check to see
if one item belongs as part of another item. Having an Item Id inside Item
Optional Fields would allow for a “Parent” or “Set” Id to be deﬁned. The group
agreed that the schema should be changed to allow Item Id to exist within Item
Optional Fields as a repeatable element.
* Possible editorial defects within the standard
The group began to discuss a list of possible defects that had been identiﬁed
during the version 2 ﬁnalization in the fall of 2008. OʼBrien suggested, though,
that the list was created at a time when the standard was being scrutinized, and
they had already been reviewed by a small group of people. He recommended
that the full list be accepted as defects. Walsh agreed to ensure that they are
corrected in the standard.
Wanner asked if anyone had other items that should be considered as part of a future
update. Jensen raised an issue with Lookup User. “Is it intended,” he asked, “to
represent a search for a valid record in the database or a user who is allowed to
perform a given task?” Walsh suggested that the answer depends heavily on the
context in which Lookup User is used. “There may be uses for the information that have
nothing to do with anything the ILS might know about,” he said. “As a result, how would
the ILS know whether to return a valid or an invalid record?” Brown added that the
information necessary to make that decision is already available in other parts of the
Lookup User Response. Jensen asked speciﬁcally about a user with a lost card.
“Should I respond with the user data or deny the lookup and return a problem element?”
He said that if the request does not include the Block Or Trap User Optional Element
then the initiator has no way to know that the card has been reported lost. Stewart
suggested that it is the responsibility of the initiator to include the Block Or Trap element
in the request if that information is relevant to the purposes for which the request was
made.
Mechanisms for Tracking Extensions and Lists
Wanner asked what we need to do to report and publish lists and extensions. Brown
suggested that there is no need for an approval process because the intent is to simply
let people know what has already been done. OʼBrien suggested the need for a
template or on-line form for people to ﬁll out and submit. Sevcik asked whether the lists
are things people would be creating or extending, or are they references to things in the
protocol. Wanner explained that in version 1, there were a set of known lists
15 of 29(implemented as enumerations and scheme/value pairs). In version 2, we made all of
them into simple string values with optional schemes. “The lists should represent what
was in version 1,” she said. Brown asked where the lists would be housed, and Wetzel
suggested that would likely be part of the larger question regarding using NISOʼs
website for NCIP. Walsh asked if the lists should be machine readable. OʼBrien asked
what value is gained if the lists are machine readable. Brown suggested that the URI
might point to the machine readable copy of the list, but Walsh indicated that URIs are
not required to resolve to a physical entity. Jackson recommended that, since we are
unable to show a strong demand for the lists to be machine readable, we should not
require that to be part of the implementation until a need can be demonstrated.
The group then shifted the discussion to what the lists should contain. Jensen observed
that the real challenge may be getting everyone to agree on the actual list members.
He recommended that we start with the lists that were deﬁned in version 1 and add or
remove items as desired. Brown suggested that we make an effort to determine those
lists that are actually being used and start with those. “I have only one list that is
important to my implementation - Agency User Privilege,” she said. Jensen added
“Thatʼs one of the lists I wouldnʼt be able to provide. Each of my customers creates his
or her own list.” OʼBrien reminded the group how difﬁcult it has been to attempt to close
lists in the past. “There will always be value outside the various lists that we come up
with,” he said, and he offered 17th century French sheet music as an example of a valid
media type that is unlikely to be part of a canonical list. Walsh asked how many lists
exist. The group concluded that there are approximately 52 elements whose values
might come from lists. Wanner said that, when we made the decision to make these
elements into strings, there was a strong feeling that we wanted to continue to use the
existing lists. Jensen added that we wanted an easy way to extend the lists, and
making them strings allows us to extend them. “Whatʼs the value, then, in maintaining
centralized lists of these strings?” Brown asked. Jackson replied that without a
centralized list each implementer would have to contact each of the other implementers
to ﬁnd out what values are supported. Wetzel asked whether the centralized list would
make it easier for new implementers. Jensen suggested that having the lists deﬁned in
the standard (rather than externally such as on a website) make them most accessible
to new implementers. “However,” Wanner added, “that limits the potential for change.”
Brown said that having them in the standard in version 1 may have introduced
confusion. “Some of us felt that the lists in the standard were THE lists; others felt they
were just examples.” OʼBrien raised a concern that, by creating ﬁnite lists, we are
declaring limits. “For any particular library,” he said, “their needs will be inside or
outside that limit. Some libraries may, then, decide they cannot implement because
their desired value is not in the list.” Jensen pressed the need for a list, particularly to
clarify potential ambiguity over spelling, casing, syntax, etc. Wanner agreed and
suggested that we should at least recreate the lists that existed as part of version 1.
She further suggested that they be clearly marked as examples and that implementers
are not required to support the speciﬁc values. Many in the group, though, continued to
raise questions over where the lists should exist (Jackson and Wanner suggested they
might belong in the application proﬁles), how many of the lists are likely to have
convergent and easily agreed upon members, and how many of the lists are likely to be
16 of 29used. Wanner concluded that the group was unable to reach a decision on how to
document lists, and further discussion was deferred until the group could review the
messages that are implemented.
Intent to Implement Version 2
Wetzel raised a concern over whether vendors truly intended to implement version 2.
OʼBrien asked the group whether anyone intended not to implement version 2, and no
one responded.
Wednesday, April 15
On-Line Survey to Determine Viability of NCIP
Wanner asked Jackson to summarize the work she and Campbell have been doing to
create a on-line form or survey that customers could use to determine whether NCIP is
a viable mechanism to facilitate interoperability among their various vendors to
accomplish their goals and objectives. Jackson explained that the hope is to have an
interactive web tool that allows customers to input the tasks and actions they want to
perform and have the system indicate whether a given combination of back-end
systems support those workﬂows via NCIP. Wanner expressed a concern that the
current state of the industry does not have enough working implementations for an
automated system like this to be comprehensive. Jackson asked whether it would be
more valuable to limit the form to only those options that are available today.
“However,” she continued, “as a customer I still want to perform those tasks even if they
are not support by an implementation via NCIP.” Brown indicated that the presentation
of the material might be too technical for many librarians. Jackson agreed that there
might be a need to show both views of the information - the technical details and the
high-level desired outcomes. Brown and Wanner both suggested that any automated
tool needs to remain vendor-neutral and not misrepresent information by limiting the
scope to only certain workﬂows.
Wanner asked if it might be possible to simplify and shorten the questionnaire by
combining various workﬂows that do the same thing but with different pieces. Jackson
indicated that the plan is to have the answers early questions limit the scope of what is
presented later in the survey. Wanner and Jackson continued to discuss the
correlations between existing application proﬁles, existing implementations, and the
options presented in the hypothetical survey. They used DCB as the primary example.
“When Campbell started working on this,” Jackson explained, “she assumed that DCB
would not have a broker. The proﬁles are written to speak directly as well, not going
through a third party.” Jensen suggested that application proﬁles should be written from
the perspective of what needs to be accomplished not how it is implemented. Jackson
said that the original proﬁles focus more on the “how.” She volunteered to work with
Campbell to review and reﬁne the survey in an attempt to simplify it and focus on tasks
and workﬂows rather than on the messages necessary to implement them.
17 of 29Simplifying Application Proﬁles
Wanner said that proﬁles focused on “what” would be more valuable. “Whatʼs in DCB-1
and DCB-2 differ mostly in ʻhow,ʼ” she said. OʼBrien provided a simple illustration of this
point, showing how the ILS systems and the broker are really roles, not necessarily
separate systems. “I think a librarian would tend to focus solely on the tasks and the
outcomes,” he said. “I think the questions should focus more on the real-world functions
and where they can happen. We can infer from that what parts may be supported. The
broker, for example, is a capability - it does not have to be a system. If we could grasp
that concept, we might be able to harmonize the various DCB proﬁles. Whether the
function exists inside or outside the ILS is irrelevant.”
18 of 29Jensen suggested that, by harmonizing and reducing the number of proﬁles, the degree
to which we are able to interoperate goes up. OʼBrien indicated that he felt we might
have as few as two core proﬁles: one for self-service and one for resource sharing.
Jensen said we should add authentication. Wanner agreed that having C-ILL and DCB
described in a single resource sharing proﬁle “would be wonderful.” She added that, a
few years ago when a small group attempted to harmonize URSA and VDX, they
discovered that the two were relatively similar. Jackson suggested that by simplifying
the proﬁles we might get more people to support them.
Supported Messages
Wanner suggested that, as a group, we should review the last few pages of the material
Jackson presented to determine what messages are currently supported by existing
implementations.
* Accept Item: implemented by six implementations
* Authenticate User: implemented by ﬁve implementations, but is not part of version 2
Jensen observed that, while the message was removed in version 2, the
functionality it provided is available in Lookup User. The Authenticate User
message was judged to be redundant.
* Cancel Request Item: implemented by six implementations
* Check In Item: implemented by six implementations
* Check Out Item: implemented by six implementations
* Create User: implemented by three implementations
* Create User Fiscal Transaction: implemented by one implementation
*Item Checked In: implemented by ﬁve implementations
19 of 29*Item Checked Out: implemented by ﬁve implementations
*Item Recalled: implemented by one implementation
*Item Received: implemented by two implementations
*Item Renewed: implemented by three implementations
*Item Request Cancelled: implemented by three implementations
*Item Requested: implemented by four implementations
*Item Shipped: implemented by two implementations
*Item Updated: implemented by one implementation
* Lookup Agency: implemented by two implementations
* Lookup Item: implemented by six implementations
* Lookup Request - implemented by one implementation
* Lookup User: implemented by eight implementations
* Lookup Version: implemented by two implementations
* Recall Item: implemented by one implementations
Jackson and Stewart both indicated that their respective companies now support
this message as well.
* Renew Item: implemented by six implementations
* Request Item: implemented by six implementations
* Undo Check Out Item: implemented by one implementation
* Update Request Item: implemented by three implementations
OʼBrien noted that, by setting an arbitrary threshold of messages used in at least four
implementations, we have 11 core messages. If the threshold is reduced to two
implementations, the core message set grows to about 19. Wanner asked whether
Notiﬁcation Messages belong within the core set. Brown explained that, in some
implementations, notiﬁcation messages are used to tell other systems that something
happened. “While they arenʼt core to the workﬂow,” she said, “they are necessary to
keep the external systems in sync with the primary.” Stewart asked if any implemented
system takes action based on receiving a notiﬁcation. Various members responded,
indicating that some did and others did not. OʼBrien suggested that notiﬁcation
messages belong outside the core. By removing those from the initial set of 11, the
group identiﬁed a core set of eight messages: Accept Item, Cancel Request Item, Check
In Item, Check Out Item, Lookup Item, Lookup User, Renew Item, and Request Item.
Stewart suggested that we include Recall Item in this list. The group agreed to accept
those 9 messages as the NCIP Core Message Set. The group felt that this set
represents the messages necessary to support the most common transactions and
workﬂows in Resource Sharing and Self-Service implementations. Vendors should
prioritize and focus on the implementation of these messages in order to be most widely
interoperable with other systems using NCIP. Wanner agreed to work with Wetzel to
draft a press release that can be used to announce the deﬁnition of the core message
set.
20 of 29Changes To NCIP Website
Walsh reviewed changes he had made to the NCIP website based on discussions from
Tuesday on NCIP Implementers Group purpose and procedures. A few were further
reﬁned, but the group approved the result without objection.
Application Proﬁles
Wanner began a discussion to review the application proﬁles in an effort to determine
how they might need to be changed. Brown asked if there is a reason for the original
(now archived) proﬁles to remain accessible. Jackson indicated that, while useful, those
proﬁles should be clearly marked “Deprecated” or “Do Not Use.” Wanner volunteered to
make those changes to the existing documents.
The group further agreed that more work should be done towards deﬁning core
workﬂows, possibly extended with product-speciﬁc proﬁles that explain how the
workﬂows are implemented. Jackson agreed to work with Campbell in an effort to draft
this core workﬂow document.
The group continued to discuss how the Application Proﬁle template might need to
change. Jackson suggested that a new proﬁle might contain much of the same
information currently provided, but packaged differently to focus more on results.
Wanner said that we need to be careful not to lose the details that are important for
programmers. Brown indicated that the Event Table was very useful, and Wanner said
the list showing what messages and elements are supported was also helpful. Jackson
suggested that we might need two documents. “ʻService Descriptionʼ and a ʻProtocol
Implementationʼ pop into mind from the ISO ILL,” she said. Wanner agreed to review
the existing Application Proﬁle template looking for ways to further streamline it, and
Brown agreed to compare the DCB, INN-REACH, and C-ILL proﬁles to see where they
are similar. The group agreed that we should make an effort to reduce the duplication
between a core workﬂow and proﬁles.
NCIP Test Bed
Wanner asked if, by deﬁning a set of core messages, we have made it possible to
create a test bed. Jensen asked if a test bed is really just a simple responder, then
OʼBrien asked how one would test a responder. Jensen suggested that the test bed
could simply push pre-stored messages through a system and then check the results.
OʼBrien indicated that a scripted approach that exercised the various messages with
known control data might work better. Wanner observed that such a system would need
a way to perform a global reset on the data. OʼBrien said that the scripts could be
structured in such a way that the ﬁnal result is the same as the starting point. “That
works when the tests pass,” said Wanner, “but when they fail you still need a master
reset.” The group raised questions around where the test bed and its scripts would live,
who would create and maintain the system, and who would arbitrate and determine
whether the results are appropriate. Brown suggested that the effort to build and
21 of 29maintain a test bed might be better invested in creating and extending actual
implementations. Wetzel offered that building a test bed would be supporting the
standard, and that is part of the purpose of this group. The group agreed that, at this
time, the test bed idea seems like a larger challenge than we are prepared to tackle.
Instead, the group agreed to update the implementation status information currently
accessible on the website. When a core workﬂow document exists, the group will again
update the implementation information using the new format.
NCIP Advertisement Promoting Version 2
Wetzel presented a draft copy of an ad promoting NCIP version 2 that is planned for
inclusion in an upcoming NISO publication. Most of the content had been drawn from
materials published as part of the version 2 balloting process, and the group concluded
that the ad should target a different audience by focusing more on tangible examples of
simpliﬁcation and real-world beneﬁts. The group worked collaboratively to reﬁne the ad,
and Wetzel submitted the edited copy to NISO.
NISO RFP Guidelines
Wanner suggested that a small group should be created to revise the existing RFP
Guidelines. She volunteered to participate, and Jackson agreed that either she or (Ted)
Koppel would help. The goal is to have the draft of a revision in front of the larger group
within six months.
LITA Presentation
Wanner agreed to check on the status of the presentation that was submitted for this
yearʼs LITA conference.
Implementation Checklists
Brown and Jackson agreed to work together in an attempt to merge the various
versions of the implementation status forms and checklists that currently exist.
LAMA / RUSA-STARS
Wanner indicated that LAMA / RUSA-STARS held a discussion forum at ALA mid-winter,
and they had plans to have a similar session at ALA summer in Chicago. She agreed to
contact Nada Vaughn in an effort to get more information. Others in the group
suggested that we should have handouts promoting NCIP (possibly copies of the ad)
and/or placards in vendor booths at ALA.
Other Efforts to Promote NCIP
Wanner requested that people bring to her attention ideas about other forums for
promoting NCIP. She asked also that people send her any informational or educational
22 of 29information relating to NCIP they may be able to ﬁnd in their own personal document
stores.
Extensions
Jensen asked how people who implement extensions document and publish them for
others to use. Wanner said there are really two goals. “One is the discovery,” she said.
“Unless you know about them, your interoperability will suffer. The other is to
incorporate extensions into later versions of the standard.” Walsh asked what
information about the extension is valuable and needs to be published. The group
deﬁned the following as a list of details that might be relevant:
* Why it was implemented
* The details of the change
* What element is being extended
* XML namespace, if used
* The version(s) affected
Wanner asked if extensions should be vetted or approved by this group. The group
agreed that extensions should simply be published without any explicit approval.
However, the group will actively select those that should be included in future versions.
The group agreed to leave open the details for a mechanism for publishing extensions.
Lists
The group reopened the topic of publishing lists. After some discussion, though,
OʼBrien noted that the lists that were part of version 1 are present in version 2 as nonnormative appendices. While having them included as part of the standard
documentation ﬁlls the need to provide examples of list values, it does not address the
need to allow the lists to change over time. The group agreed that the appendices are
sufﬁcient for now, and additional list values can be deﬁned as part of application
proﬁles.
Thursday, April 16
Action Items and Parking Lot
Wanner and Walsh reviewed the action items and the parking lot from the two prior
days.
Next In Person Meeting
Wanner asked the group whether another in person meeting is needed this year.
Wetzel suggested that, if the group ultimately decides to adopt continuous maintenance,
another meeting might be justiﬁed. Wanner agreed to begin at least tentatively planning
a meeting for the fall. Wetzel (NISO - Baltimore), Stewart (Relais - Ottawa), and OʼBrien
23 of 29(OCLC - Dublin, OH) offered to host. Each agreed to determine whether facilities are
available for a meeting tentatively scheduled for September 22-24, 2009. Based on
availability, the group will make a decision in the near future.
Conference Call Schedule
Wanner outlined the conference call schedule for the remainder of this year. Each call
is scheduled for the third Thursday of the month at 2 pm Eastern / 11 am Paciﬁc.
* May 21
* June 18
* No call in July due to ALA
* August 20
* September 17 (if necessary to plan last minute details for in person meeting)
* October 15
* November 19
* December 17
Meet and Greet at ALA
Brown suggested that we might want to organize a meet and greet at ALA. “That would
allow those who havenʼt been active to get re-involved,” she said. “It might help, too,
attract new members.” The group agreed to think about organizing a meet and greet for
Sunday evening during ALA. The time and location are to be determined.
Adjournment
Wanner adjourned the meeting.
24 of 29Appendix A - Action Items
The following list represents the various action items that need to be completed as a
result of this meeting. The person to whom the items are assigned is responsible for
reporting back to the group a date by which the items can be completed.
What Who By When
Review NISO website/workspace and
make recommendation about moving
NCIP website
Change “Manage and Approve Application
Proﬁles” to “Collect and Publish
Application Proﬁles” in the NCIP IG
Purpose section on the website
Add Brent Jensen to NCIP IG members as
secondary rep for SirsiDynix
Add Ted Koppel to NCIP IG members as
secondary rep for Auto-Graphics
Revise wording on NCIP IG members page
explaining the one vote per organization
and the designation of primary and
secondary members
Revise wording on NCIP IG members /
procedures page to reﬂect use of NISO
Policies and Procedures guidelines for
committee membership
Send notices to current but inactive NCIP
IG members whose membership will be
revoked as a result of moving to NISO
Policies and Procedures
Remove inactive members from list on
website
Add “Assure balanced representation
within the membership of those interested
in NCIP” to the NCIP IG purpose
Remove “Acquire feedback and
requirements from end users” from the
NCIP IG purpose
Change “Candy Zemon” to “Gail Wanner”
as contact person for requesting
membership in NCIP IG
Remove “Organization must be an NCIP
developer” from NCIP IG procedures
Remove “Attendees at the ﬁrst meeting
are members” from the NCIP IG
procedures
Walsh, Wetzel
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
Wanner, Wetzel
Walsh After notices sent to inactive
members
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
25 of 29What Who By When
Remove “Chair is always a voting
member” from the NCIP IG procedures
Change “Two thirds of the participants in
vote count as a majority” to “Two thirds of
the NCIP IG membership is required to
take a vote. 50% + 1 vote is required for
the vote to pass.” in the NCIP IG
procedures
Remove “Chair is the only person who
approves the voting process” from the
NCIP IG procedures
Remove “Chair decides if reconsideration
of decisions is warranted” from the NCIP
IG procedures
Add “Chair is elected by the group for an
unspeciﬁed term” to the NCIP IG
procedures
Add “Any group member may call for a
vote for a chair at any time” to the NCIP IG
procedures
Review requirements for converting to
Continuous Maintenance and prepare list
of decisions that will need to be made
Prepare task-oriented workﬂows for major
self-service tasks (i.e., checkout, pay fee,
update patron data, etc.) as a starting
point for establishing a generic self service
core proﬁle
Provide editable version of Standard
Update list of examples of p.57 of Part 1 of
the Standard to include “Borrower” and
“Lender” (as location types)
Fix typographical error on p.57 of Part 1 of
the Standard - “Text siring” should be
“Text string”
Allow Bibliographic Id and Item Id to be
both repeatable and not mutually exclusive
in Request Item. (At least one
Bibliographic Id or Item Id must be
present, but both can be present and both
can repeat.)
Allow Bibliographic Record Id to be
repeatable in Bibliographic Description of
Accept Item
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
Walsh DONE
Walsh, Wetzel
Walsh, Boettcher
Wetzel
Walsh After NISO provides editable
version of Standard
Walsh After NISO provides editable
version of Standard
O’Brien
O’Brien
26 of 29What Who By When
Prepare “Release Notes” describing the
changes to make Bibliographic Id and Item
Id repeatable and not mutually exclusive
AND to make Bibliographic Record Id
repeatable in Bibliographic Description in
Request Item. Release Notes should
describe not only the change, but also the
motivation behind the change.
Update the Standard to be consistent with
the Schema with respect to the
repeatability of the Problem element.
Add Item Id as a repeatable element within
Item Optional Fields
Prepare “Release Notes” describing the
change to add Item Id to Item Optional
Fields
Update Standard to address defects
identiﬁed as part of Fall 2008 push to
publish Version 2 and documented in email
from Walsh to NCIP list on March 15, 2009
Remove old RFP guidelines link
Establish a “Success Stories” area on the
website.
Prepare documentation for NCIP Core
Message sets (Resource Sharing and Self
Service)
Prepare press release announcing core
message sets
Begin drafting a “core workﬂow”
document
Edit existing archived proﬁles to add
information indicating that they should no
longer be used
Add wording to the archived proﬁles
portion of the website to indicate that
these proﬁles should no longer be used.
They are meant only as examples.
Review current application proﬁle
template looking for ways to further
streamline
Compare DCB, INN-REACH, and C-ILL
proﬁles for similarities
Provide updated information for vendor
status reports
Post updated information for vendor
status reports
Walsh
Brown After NISO provides editable
version of Standard
O’Brien
Walsh
Walsh After NISO provides editable
version of Standard
Walsh
Walsh
Wanner
Wetzel, Wanner, Walsh
Jackson, Campbell
Wanner
Walsh
Wanner
Brown
Group
Walsh As information is received from
members
27 of 29What Who By When
Attempt to merge two different
perspectives on implementation status
forms
Revise RFP Guidelines and submit to
group for review
Check on status of LITA presentation
Continue work on a tool for identifying
NCIP compliant systems
Check on plans for LAMA / RUSA-STARS
session at ALA summer
Look for any existing NCIP tutorial or
education materials (documents,
presentations) and send to Wanner
Look for opportunities to promote NCIP -
user group meetings, conferences, etc. -
and inform Wanner
Determine whether potential host sites are
available for a in person meeting in
September (9/22-24)
Work with NISO to establish an NCIP IG
listserve and a general interest listserve
(migrating the current TLC-hosted list
membership)
Publish meeting minutes
Jackson, Brown
Wanner, Jackson, Koppel Within 6 months
Wanner
Jackson, Campbell
Wanner
Group
Group
Stewart, O’Brien, Wetzel
Walsh, NISO
Walsh
28 of 29Appendix B - Parking Lot
Decisions were deferred on the following items.
Item Deferred Until
Review “List discussions follow same rules
but have a duration, exceeding which counts
as an abstention” in NCIP IG procedures
Review “Default email vote duration is one
week. Chair may reduce or extend at own
discretion” in NCIP IG procedures
Standardize mechanism for requesting
optional information in an lookup request
Resubmit implementation status information
Review materials prepared around tasks,
workﬂows, and core messages to determine
if new generic application proﬁles can be
created
Decision is made about where and/or how to host
NCIP website
Decision is made about where and/or how to host
NCIP website
Next change which breaks backward compatibility
(probably v3)
When (and if) we have a new form for reporting
implementation status
After core message documentation, core workﬂow
documentation, and proﬁle templates have been
prepared and/or revised
29 of 29