1、ANSI/NISO Z39.83-2-2008 ISSN: 1041-5653 NISO Circulation Interchange Protocol (NCIP) Part 2: Implementation Profile 1 Abstract: A practical implementation structure for the NISO Circulation Interchange Part 1: Protocol (NCIP) is defined. An American National Standard Developed by the National Inform
2、ation Standards Organization Approved November 11, 2008 by the American National Standards Institute Published by:NISO, Baltimore, Maryland, U.S.A.About NISO Standards NISO standards are developed by the Standards Committees of the National Information Standards Organization. The development process
3、 is a strenuous one that includes a rigorous peer review of proposed standards open to each NISO Voting Member and any other interested party. Final approval of the standard involves verification by the American National Standards Institute that its requirements for due process, consensus, and other
4、 approval criteria have been met by NISO. Once verified and approved, NISO Standards also become American National Standards. This standard may be revised or withdrawn at any time. For current information on the status of this standard contact the NISO office or visit the NISO website at: http:/www.
5、niso.org Published by NISO One North Charles Street Suite 1905 Baltimore, MD 21201 www.niso.org Copyright 2008 by the National Information Standards Organization All rights reserved under International and Pan-American Copyright Conventions. For noncommercial purposes only, this publication may be r
6、eproduced or transmitted in any form or by any means without prior permission in writing from the publisher, provided it is reproduced accurately, the source of the material is identified, and the NISO copyright status is acknowledged. All inquires regarding translations into other languages or comm
7、ercial reproduction or distribution should be addressed to: NISO Press, One North Charles Street, Suite 11905, Bethesda, MD 21201. ISSN: 1041-5653 (National Information Standards Series) ISBN: 978-1-880124-78-9 ANSI/NISO Z39.83-2-2008 i Contents Foreword iii 1 Purpose. 1 2 Scope. 1 3 Normative Refer
8、ences . 1 4 Definitions. 2 4.1 Notational Convention . 2 5 Encoding. 3 5.1 Message Encoding and Structure . 3 5.1.1 XML Schema 3 5.1.2 Compression 3 5.2 Character Representation . 3 5.3 Representation of Data Types. 4 6 Required Components. 7 6.1 Required Services . 7 6.2 Required XML Prolog 7 6.2.1
9、 XML Namespace . 8 6.3 Required Data Structures 8 6.3.1 Message Headers 8 6.3.2 Version Attribute. 8 6.4 Requirements and Restrictions on Data Elements 9 6.4.1 Lists of Values for Certain Data Elements . 9 6.5 Required Behavior Rules. 10 6.5.1 Declaration of Success 10 6.5.2 Omission of Requested El
10、ements 11 6.5.3 Data Elements to be Included in Service Responses 11 6.5.4 Null Values. 11 6.5.5 Update Processing. 11 6.5.6 Mandated Action 11 6.5.7 Denial of Access 12 6.5.8 Error Identification 12 6.5.9 Agency Id . 12 6.5.10 Persistent Ids . 12 7 Transport Protocol. 13 7.1 Implementations Acting
11、as Initiators 13 7.2 Implementations Acting as Responders 13 7.3 HTTP/HTTPS Message Headers 13 7.4 Direct Transmission via TCP/IP. 14 8 Security . 14 ANSI/NISO Z39.83-2-2008 ii 9 Scheme /Profile Registration.14 10 Extension.14 Appendix A (normative) NCIP XML Schema .15 Appendix B (informative) Defin
12、itions of Values for Use in Some Sample Lists of Values 16 Appendix C (informative) Preliminary Registry of Schemes Defined for Optional Use with NCIP27 Bibliography 32 ANSI/NISO Z39.83-2-2008 iii Foreword (This foreword is not part of the NISO Circulation Interchange Protocol (NCIP) Part 2: Impleme
13、ntation Profile 1, ANSI/NISO Z39.83-2-2008. It is included for information only.) About This Standard This Implementation Profile has been developed to provide a practical implementation structure for the NISO Circulation Interchange Part 1: Protocol (NCIP). The Foreword to Part 1 provides a complet
14、e description of the reasons for the NCIPs development and the reasons for describing the physical implementation of the NCIP within an Implementation Profile rather than within the NCIP itself. In brief, the committee decided that this approach would improve the extensibility of the NCIP. This appr
15、oach also allows the community of application providers and users to adapt the implementation profile to changing technology. Version 2 includes radical changes to the protocol. It is not backward compatible with version 1, as it is based solely on an XML Schema. The version 2 changes build on chang
16、es made since original publication of NCIP and known collectively (if inaccurately) as version 1.01, the version several implementers are already using. There are a few other changes that also break backward compatibility. The most significant are in error handling and extensibility. A complete chan
17、ge list for version 2 (including the incorporated changes from version 1.01) is posted on the NCIP website: www.ncip.info. Principles In making decisions about this Implementation Profile 1 the committee examined ways to facilitate rapid and widespread implementation of the NCIP. Two goals drove dec
18、ision-making: make it easy for service providers to use NCIP in a variety of applications and make it easy for them to build those applications quickly. From these goals, the committee developed the following principles: Use technology that is widely supported. This dictated choosing options that of
19、fered the most robust support for application development. Stay with the curve. NCIP will be embedded in applications that last an average of several years, if not longer. This requires choosing technology likely to stand the test of time. In some cases, this meant rejecting very promising technolog
20、y when it was not clear that the technology would be widely adopted. As noted below, the committee deliberately built bridges to emerging technology where possible. These were judgment calls, not matters of precise calculations. Several areas deserve particular mention: Message Encoding and Structur
21、e The committee chose Extensible Markup Language (XML) over ASN.1/BER, which has been widely used in library applications. XML is supported by a large number of organizations and tool providers. This provides implementers with a choice of tools. In addition, the expectation is that it will be the do
22、minant encoding method used in Internet communication. This widespread usage will help those using the NCIP for library applications to connect libraries to the broader stream of information services available in todays electronic environment. Extensibility The Foreword to Part 1 discusses the varia
23、tion in circulation practice and the need for a flexible mechanism for supporting variation in practice and local policy. The business rules that enforce these policies often use enumerated data types to characterize those policies. In some cases these are defined in existing authoritative lists; in
24、 other cases, the lists are maintained locally by an agency or a consortium. In either case, the expectation is that the definition of the enumerated types will be independent of the XML Schema definition for NCIP messages. The committee has adopted a data structure that allows for an optional Schem
25、e attribute on data elements that tend to be values drawn from lists of values (authoritative or local) while leaving implementers free to use values without the mandated constraint of pre-defined lists.” ANSI/NISO Z39.83-2-2008 iv Character Encoding The committee chose Unicode (UCS-2) for character
26、 encoding because the protocol messages may carry character data unsupported by the ASCII character set (American Standard Code for Information Interchange, ANSI X3.4-1 986). UTF-8 was chosen as the encoding scheme. Using UTF-8 is consistent with the Internet Engineering Task Force (IETF) mandate fo
27、r the use of Unicode in Internet standards. UTF-8 will allow applications that only require support provided by ASCII encoding to use ASCII and remain compliant with this IMP 1. Message Transport The committee carefully considered the options for specifying transport protocols. Two aspects of the an
28、ticipated implementations drove the decision-making: 1. The NCIP will be implemented extensively in applications that cross administrative domains. In these applications, secure transmission is a critical issue. 2. In many cases NCIP messages will be embedded within Web applications, but in others,
29、notably self-standing kiosk applications, the use of Web protocols might be difficult. For these reasons, the IMP1 allows applications to use one of three transport protocols: hypertext transport protocol (HTTP), hypertext transport protocol with secure socket layer (HTTPS), and TCP/IP. The initiati
30、ng application selects the transport mechanism and the responding application must respond using that transport. These choices may be restricted by an application profile. The committee also considered using Simple Object Access Protocol (SOAP). While it had several advantages, the committee chose n
31、ot to adopt it because SOAP is not currently a fully approved protocol. Trademarks, Service Marks Wherever used in this standard, all terms that are trademarks or service marks are and remain the property of their respective owners. NISO Voting Members At the time NISO approved this standard, the fo
32、llowing organizations were voting members: 3M AIIM ARMA International American Association of Law Libraries American Library Association American Psychological Association American Society for Indexing American Society for Information Science the most current version of the standards should be used.
33、 See the Bibliography for additional references that are cited in informative sections of the standard. ANSI/NISO Z39.83-1-2008, NISO Circulation Interchange Part 1: Protocol (NCIP) IETF RFC2119, Key words for use in RFCs to Indicate Requirement Levels, March 1997 IETF RFC 2396, Uniform Resource Ide
34、ntifiers (URI): Generic Syntax, August 1998 IETF RFC 2616, Hypertext Transfer Protocol HTTP/1.1; June 1999 ISO 4217, Codes for the representation of currencies and funds ISO 8601, Data elements and interchange formats Information interchange Representation of dates and times ISO 10646, Information T
35、echnology Universal multiple-octet coded character set (UCS) The Unicode Consortium, The Unicode Standard Version 5.0, 2007 (ISBN 0-321-48091-0) ANSI/NISO Z39.83-2-2008 2 W3C Recommendation, Character Model for the World Wide Web 1.0: Fundamentals; February 15, 2002 W3C Recommendation, Extensible Ma
36、rkup Language (XML) 1.0, fourth edition; September 29, 2006 W3C Recommendation, XML Schema Part 2: Datatypes, second edition, October 28, 2004 4 Definitions The following terms, as used in this standard, have the meanings indicated. Term Definition Strictly Conformant An implementation is strictly c
37、onformant to this IMP1 and the NCIP if the implementation always behaves as mandated in this IMP1 whenever it exchanges messages (either as initiator or responder) with another implementation. Conformant An implementation is conformant to this IMP1 and the NCIP if the implementation behaves as if it
38、 were a strictly conformant implementation whenever it exchanges messages (either as initiator or responder) with a strictly conformant implementation. IMP1 NISO Circulation Interchange Protocol (NCIP) Part 2: Implementation Profile 1, ANSI/NISO Z39.83-2-2008. Initiating Implementations NCIP Impleme
39、ntations that initiate NCIP services. Protocol NISO Circulation Interchange Part 1: Protocol (NCIP), ANSI/NISO Z39.83-1-2008. Unless otherwise specified, the NCIP Responding Implementations Implementations that respond to NCIP messages sent to them by initiating implementations. Supported Recognized
40、 by the implementation but not necessarily used by the implementation beyond NCIP messaging per se. 4.1 Notational Convention The key words “must“, “must not“, “required“, “should“, “should not“, “recommended“, “may“, and “optional“ in this Standard are to be interpreted as described in IETF RFC 211
41、9. ANSI/NISO Z39.83-2-2008 3 5 Encoding This IMP1 specifies required behavior with regard to encoding in three contexts, as follows: Message encoding and structure Character representation Representation of data types 5.1 Message Encoding and Structure 5.1.1 XML Schema For the purposes of this IMP1,
42、 conformant messages must be valid according to the rules for valid documents specified in the XML standard. For each message governed by the NCIP there is an element in the “NCIP XML Schema”. For the XML Schema, see Appendix A. The following URL should be consulted for any changes or revisions that
43、 may have occurred subsequent to the publication of this Standard: Each message shall contain one and only one NCIP Message element as defined in the NCIP XML Schema. 5.1.2 Compression This Implementation Profile does not define compression mechanisms. However, implementations should consider suppor
44、ting optional mechanisms that, by agreement with peer implementations, can be enabled. Examples of compression mechanisms are: Using an XML Stylesheet to substitute shorter element names, such as “AI” for “Agency Id” Using HTTP content-encoding (i.e. gzip compression) 5.2 Character Representation Fo
45、r the purposes of this IMP1, conformant messages must employ the UTF-8 encoding of Unicode (UCS-2) as the encoding for all data. All applications must have the ability to recognize any character defined in 16-bit Unicode (UCS-2) as a valid character. Applications are not required by this IMP1 to dis
46、play, edit, or process all Unicode characterseach application may choose any subset of Unicode characters it will support in sending and receiving messages. Applications conforming to this IMP1 that make use of string identity matching must adhere to the requirements of Section 6 (“String Identity M
47、atching“) of Character Model for the World Wide Web 1.0 for strings to be matched. This implies that applications that compare text in data elements in incoming messages for identity with text supplied in outgoing messages, as might be the case with unique identifiers, should ensure that such text i
48、n outgoing messages is normalized sufficiently well that further normalization by the recipient of the message will not affect the ability to compare for identity. Any valid character representation, including character references and entity references, must be supported. However, as the NCIP XML Sc
49、hema does not define any entity references, in practice the permissible entity references are restricted to “amp“ (ampersand), “lt“ (less than), “gt“ (greater than), “apos“ (apostrophe), and “quot“ (quote). ANSI/NISO Z39.83-2-2008 4 5.3 Representation of Data Types The data types employed by messages conforming to this IMP1 are defined in this section. The XML Schema governing the structure of conformant messages under this IMP1 employs what are commonly called “fixed attributes” to specify data types of all simple elements. The data types are presented here in alphabet
