1、raising standards worldwide NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW BSI Standards Publication BS ISO/IEC 20944-3:2013 Information technology Metadata Registries Interoperability and Bindings (MDR-IB) Part 3: API bindingsBS ISO/IEC 20944-3:2013 BRITISH STANDARD National
2、 foreword This British Standard is the UK implementation of ISO/IEC 20944-3:2013. The UK participation in its preparation was entrusted to T e c h n i c a l C o m m i t t e e I S T / 4 0 , D a t a m a n a g e m e n t a n d i n t e r c h a n g e . A list of organizations represented on this committee
3、 can be obtained on request to its secretary. This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application. The British Standards Institution 2013. Published by BSI Standards Limited 2013. ISBN 978 0 580 53627 4 ICS 35.040
4、 Compliance with a British Standard cannot confer immunity from legal obligations. This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 January 2013. Amendments issued since publication Date T e x t a f f e c t e dBS ISO/IEC 20944-3:2013Referen
5、ce number ISO/IEC 20944-3:2013(E) ISO/IEC 2013INTERNATIONAL STANDARD ISO/IEC 20944-3 First edition 2013-01-15 Information technology Metadata Registries Interoperability and Bindings (MDR-IB) Part 3: API bindings Technologies de linformation Interoprabilit et liaisons des registres de mtadonnes (MDR
6、-IB) Partie 3: Liaisons API BS ISO/IEC 20944-3:2013 ISO/IEC 20944-3:2013(E) COPYRIGHT PROTECTED DOCUMENT ISO/IEC 2013 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopyi
7、ng and microfilm, without permission in writing from either ISO at the address below or ISOs member body in the country of the requester. ISO copyright office Case postale 56 CH-1211 Geneva 20 Tel. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org Web www.iso.org Published in Switzerla
8、nd ii ISO/IEC 2013 All rights reservedBS ISO/IEC 20944-3:2013 ISO/IEC 20944-3:2013(E) ISO/IEC 2013 All rights reserved iiiContents Page Foreword . v Introduction vi 1 Scope 1 2 Normative references 1 3 Terms and definitions . 1 4 Intended use of this part of ISO/IEC 20944 . 1 5 Abstract model 2 5.1
9、General . 2 5.2 Session paradigm 2 5.3 Security framework . 3 5.4 Hierarchical navigation paths 3 6 Services 4 6.1 Use of ISO/IEC 13886 4 6.2 Session establishment services 4 6.3 Session parameter services . 8 6.4 Security services . 9 6.5 Data transfer services . 11 6.6 Miscellaneous 21 7 Bindings
10、. 26 8 Administration . 26 9 Conformance . 26 9.1 API conformance paradigm 26 9.2 API application . 26 9.3 API environment 26 9.4 Conformance labels 27 10 Reserved for future standardization 27 11 C API binding . 27 11.1 Datatype mapping . 27 11.2 Function parameter mapping . 28 11.3 Function return
11、 mapping 28 11.4 Function exception mapping . 28 11.5 Procedure call signatures 28 11.6 Error/exception returns. 36 11.7 Conformance label prefix . 37 12 Java API binding 37 12.1 Datatype mapping . 37 12.2 Function parameter mapping . 37 12.3 Function return mapping 38 12.4 Function exception mappin
12、g . 38 12.5 Procedure call signatures 38 12.6 Error/exception returns. 44 12.7 Conformance label prefix . 45 13 ECMAScript API binding . 45 13.1 Datatype mapping . 45 13.2 Function parameter mapping . 45 BS ISO/IEC 20944-3:2013 ISO/IEC 20944-3:2013(E) iv ISO/IEC 2013 All rights reserved13.3 Function
13、 return mapping 46 13.4 Function exception mapping 46 13.5 Procedure call signatures .46 13.6 Error/exception returns .54 13.7 Conformance label prefix 54 Bibliography 55 BS ISO/IEC 20944-3:2013 ISO/IEC 20944-3:2013(E) ISO/IEC 2013 All rights reserved vForeword ISO (the International Organization fo
14、r Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective or
15、ganization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information techn
16、ology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of the joint technical committee is to prepare International Standards. Draft International Standard
17、s adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. Attention is drawn to the possibility that some of the elements of this document may be the subj
18、ect of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. ISO/IEC 20944-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 32, Data management and interchange. ISO/IEC 20944 consists of the following
19、 parts, under the general title Information technology Metadata Registries Interoperability and Bindings (MDR-IB): Part 1: Framework, common vocabulary, and common provisions for conformance Part 2: Coding bindings Part 3: API bindings Part 4: Protocol bindings Part 5: Profiles BS ISO/IEC 20944-3:20
20、13 ISO/IEC 20944-3:2013(E) vi ISO/IEC 2013 All rights reservedIntroduction The ISO/IEC 20944 series of International Standards provides the bindings and their interoperability for metadata registries, such as those specified in the ISO/IEC 11179 series of International Standards. This part of ISO/IE
21、C 20944 contains provisions that are common to API bindings (Clauses 4-10) and the API bindings themselves (Clause 11 onward). The API bindings have commonality in their conceptualization of the services provided. For example, common features include: using a session paradigm to access data; using a
22、 parameterized security framework to support a variety of security techniques; using a hierarchical navigation for data access. Clause 11 and onward are the actual API bindings themselves. The clauses of this part of ISO/IEC 20944 are organized such that future amendments are possible, which would i
23、nclude additional API bindings. BS ISO/IEC 20944-3:2013 INTERNATIONAL STANDARD ISO/IEC 20944-3:2013(E) ISO/IEC 2013 All rights reserved 1Information technology Metadata Registries Interoperability and Bindings (MDR-IB) Part 3: API bindings 1 Scope The ISO/IEC 20944 series of International Standards
24、describes codings, application programming interfaces (APIs), and protocols for interacting with an ISO/IEC 11179 metadata registry (MDR). This part of ISO/IEC 20944 specifies provisions that are common across API bindings for the ISO/IEC 20944 series of International Standards, and provides the ind
25、ividual API bindings themselves. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) ap
26、plies. ISO/IEC 9899:1999, Programming languages C ISO/IEC 11404:2007, Information technology General-Purpose Datatypes (GPD) ISO/IEC 13886:1996, Information technology Language-Independent Procedure Calling (LIPC) ISO/IEC 16262, Information technology Programming languages, their environments and sy
27、stem software interfaces ECMAScript language specification ISO/IEC 20944-1:2013, Information technology Metadata Registries Interoperability and Bindings (MDR-IB) Part 1: Framework, common vocabulary, and common provisions for conformance IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syn
28、tax, January 2005 3 Terms and definitions For the purposes of this document, the terms and definitions given in ISO/IEC 20944-1 apply. 4 Intended use of this part of ISO/IEC 20944 The purpose of this part of ISO/IEC 20944 is to provide a common set of services (common API provisions) and standardize
29、d API bindings such that portable programs can be written to access the MDR repositories. These programs are portable in the sense that the same program should behave similarly across all operating environments and the same program should be able to access MDR repositories that conform to this Inter
30、national Standard. BS ISO/IEC 20944-3:2013 ISO/IEC 20944-3:2013(E) 2 ISO/IEC 2013 All rights reserved5 Abstract model 5.1 General The API bindings have commonality in their conceptualization of data access services. For example, common features include: using a session paradigm to access data using
31、a parameterized security framework to support a variety of security techniques using a hierarchical navigation for data access 5.2 Session paradigm The following state diagram describes the different states of the services: The states are: initial state: The initial state of an instance of the API.
32、end state: The final state of an instance of the API. ready: The API is ready to for service requests. authentication-authorization: The API is processing an authentication-authorization request. data transfer: The API is processing a data transfer request. The events are: connect: Setting up the in
33、itial connection. open: Adding more parameters to create a new handle and the context of a current node path for that handle. close: Destroying a handle created by open. disconnect: Knocking down a connection. BS ISO/IEC 20944-3:2013 ISO/IEC 20944-3:2013(E) ISO/IEC 2013 All rights reserved 3 request
34、: A data transfer request. response: A data transfer response. auth request: An authentication-authorization request. auth response: An authentication-authorization response. 5.3 Security framework The security framework provides a common technique for accessing security services and supports a comm
35、on technique for implementing security services. The common accessing technique uses the Request-Response Authorization-Authentication (RRAA) services. In the RRAA services, a Request is places for authorization, authentication, or some other security service. The Request provides the data, as requi
36、red for the particular RRAA service. The RRAA service then provides a Response to the request. The services are symmetric in that both the API application (e.g., the program using the API) and the API environment (e.g., the underlying services and infrastructure) may each make requests of the other
37、party, i.e., the API application can make requests to the API environment, and the API environment can make requests to the API application. The supporting infrastructure should provide a run-time, dynamically configurable selection of RRAA services such that programs do not need to be recompiled or
38、 re-linked to take advantage of a new RRAA services or new security technologies 1 . This International Standard makes no requirements for a particular set of security services. The available services are implementation-defined. 5.4 Hierarchical navigation paths The API services may access data via
39、hierarchical navigation paths 2 . The navigation paths are based upon Uniform Resource Identifiers, as defined in RFC 3986. Absolute paths, which start at the top of a repository, are specified in subclause 3.3 of RFC 3986 under “absolute paths“. Relative paths, which are relative to the current pat
40、h 3 , are specified in subclause 5 of RFC 3986 under “relative URIs“. The common accessing technique uses the Request-Response Authorization-Authentication (RRAA) services. In the RRAA services, a Request is places for authorization, authentication, or some other security service. The Request provid
41、es the data, as required for the particular RRAA service. The RRAA service then provides a Response to the request. The services are symmetric in that both the API application (e.g., the program using the API) and the API environment (e.g., the underlying services and infrastructure) may each make r
42、equests of the other party, i.e., the API application can make requests to the API environment, and the API environment can make requests to the API application. 1See the white paper “Making Login Services Independent of Authentication Technologies“, by Vipin Samar and Charlie Lai, that was presente
43、d at the Third ACM Conference on Computer Communications and Security (1996-03), which is available at http:/citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.8767 / sample output maximum_input_string=4095 supported_types=str8,int,char,long version_info=3.17 version_description=“C implementation
44、 with LDAP backend“ 6.2.2 Configuration Synopsis / values accessible via “._system_info“ identifier data_object_identifier_length / Maximum supported data object identifier length datatype_family_support / List of families supported identifier_character_family_support / Allowed data object identifie
45、r characters navigation_identifier_max / Maximum hierarchical navigation identifier length session_max: Maximum number of simultaneous opened sessions octet_transfer_max: / Maximum octets of data for a data object / error codes accessible via “._error_family“ and “._error_list“ error_family / Name of error code system error_list / List of error codes and meanings
