ISO/IEC TR 10182:2016基于信息处理两个主要领域的标准化经验。其中一个领域涉及编程语言。另一个领域由应用程序实现目标所需的服务组成。这些服务分为多个连贯的组，每个组称为系统设施，通过功能接口访问。系统设施的规范称为功能规范，它定义了系统功能的集合，每个功能都执行一些定义良好的服务。 由于原则上没有理由不让程序使用某个特定的系统设施，无论使用哪种语言编写，因此系统设施说明符定义一个独立于语言的“抽象”功能接口是一种实践。 通过这种方式，特定系统设施中的概念可以由该领域的专家进行细化，而不考虑语言的特殊性。定义了特定系统设施的内部一致视图，以一致的方式将系统功能彼此关联，并将系统功能与系统设施内的其他层关联，包括与整个系统中其他对象通信的协议。 然而，如果这两个领域是独立标准化的，就不可能保证程序可以从一个操作环境转移到另一个操作环境，即使程序是用标准编程语言编写的，并且只使用标准系统设施。系统设施与编程语言的语言绑定提供了映射系统设施功能接口的语言语法。 这允许用该语言编写的程序以标准方式访问构成系统设施的系统功能。语言绑定的目的是实现使用特定语言中特定设施的程序的可移植性。已经为其开发了语言绑定的系统设施的例子有GKS、NDL和SQL（参见第3条）。预计将需要进一步的语言绑定开发。目前正在标准化的一些系统设施没有语言绑定，其他系统设施将标准化。存在n×m语言绑定的可能性，其中n是语言的数量，m是系统设施的数量。 本技术报告的范围是对语言绑定方法进行分类，详细报告特定实例，并为未来的语言绑定标准提供建议指南。 请注意，语言绑定和抽象工具接口必须具有兼容的运行时表示，但抽象工具不一定必须用宿主语言编写。例如，如果应用程序使用Pascal语言绑定，并且相应的工具是用FORTRAN编写的，那么该操作环境中必须有兼容的运行时表示。如何实现这种兼容性超出了这些指南的范围。这通常是实施者定义的操作环境的属性，本技术报告对此进行了简要回顾。

ISO/IEC TR 10182:2016 is based on experience gained in the standardization of two major areas in information processing. One area covers programming languages. The other area is composed of the services necessary to an application program to achieve a goal. The services are divided into coherent groups, each referred to as a SYSTEM FACILITY, that are accessed through a FUNCTIONAL INTERFACE. The specification of a system facility, referred to as a FUNCTIONAL SPECIFICATION, defines a collection of SYSTEM FUNCTIONS, each of which carries out some well-defined service. Since in principle there is no reason why a particular system facility should not be used by a program, regardless of the language in which is written, is the practice of system facility specifiers to define an 'abstract' functional interface that is language independent. In this way, the concepts in a particular system facility may be refined by experts in that area without regard for language peculiarities. An internally coherent view of a particular system facility is defined, relating the system functions to each other in a consistent way and relating the system functions to other layers within the system facility, including protocols for communication with other objects in the total system. However, if these two areas are standardized independently, it is not possible to guarantee that programs from one operating environment can be moved to another, even if the programs are written in a standard programming language and use only standard system facilities. A language binding of a system facility to a programming language provides language syntax that maps the system facility's functional interface. This allows a program written in the language to access the system functions constituting the system facility in a standard way. The purpose of a language binding is to achieve portability of a program that uses particular facilities in a particular language. Examples of system facilities that have had language bindings developed for them are GKS, NDL, and SQL (see Clause 3). It is anticipated that further language binding development will be required. Some system facilities currently being standardized have no language bindings and additional system facilities will be standardized. There is a possibility of n × m language bindings, where n is the number of languages and m the number of system facilities. The scope of this Technical Report is to classify language binding methods, reporting on particular instances in detail, and to produce suggested guidelines for future language binding standards. Note that the language bindings and the abstract facility interfaces must have a compatible run time representation, but the abstract facility does not necessarily have to be written in the host language. For example, if the application program is using a Pascal language binding and the corresponding facility is written in FORTRAN, there must be a compatible run time representation in that operating environment. How this compatibility is achieved is outside the scope of these guidelines. This is generally a property of the operating environment defined by the implementor, and is reviewed briefly in this Technical Report.