An SQL/ERI Server will often support additional data types and SQL language facilities beyond those specified for the given level of service. This section identifies features in the SQL'92 standard, and emerging features in the SQL3 and SQL/MM specifications, that an SQL/ERI Server may support. Each of these items is an optional indication that must be explicitly declared by an SQL/ERI Server implementation before an application program can rely on its existence.

An SQL/ERI Server that supports a Read-Only interface will support only the read-only aspects of each feature. Thus a non-SQL implementation may be able to define itself to an SQL client using very complex abstract data types (ADTs) and methods specified in SQL3, even though it does not allow creation or modification of such types. The SQL/ERI server will declare the accessing "signature" of such facilities in the Information Schema, so that an application can use the SQL/PSM routine and procedure calling mechanisms to access the data. This is how the very specialized data managers such as document management systems, geographic information systems, or CAD/CAM systems may make their specialized features available to SQL applications.

5.1 SQL'92 features

The SQL conformance levels defined in Section 4 of this specification identify a broad level of capability for conforming SQL/ERI servers. In addition, it is sometimes desirable to identify other features specified in the SQL'92 standard [8] as either offered by a product or required by a specific procurement. Section 14 of FIPS SQL [3] identifies 83 features of the SQL'92 standard beyond the Entry SQL requirements. An SQL/ERI Server could identify which features are supported beyond its declared level of service by implementing the SQL_FEATURES table as specified in Section 15 of FIPS SQL. Implementation of the SQL_FEATURES table is a requirement for all SQL/ERI Servers that claim a base level of SQL data manipulation language support at the Intermediate DML level or above. A procurement could also use this list to identify, unambiguously, those SQL features beyond the identified conformance level that are either required or desirable for that procurement.

FIPS SQL also identifies default minimum requirements for the precision, size, or number of occurrences of database constructs (see section 16.6 of [3]). Unless otherwise specified in a procurement, the Entry Value sizing limits apply to all Entry SQL or Transitional SQL features and the Intermediate Value sizing limits apply to all Intermediate SQL or Full SQL features. An SQL/ERI Server could identify its own sizing limits by implementing the SQL_SIZING table as specified in Section 15 of FIPS SQL. Implementation of the SQL_SIZING table is a requirement for all SQL/ERI Servers that claim a base level of SQL data manipulation language support at the Intermediate DML level or above. A procurement is responsible for identifying its own sizing limits on all required features, but in the absence of an explicit declaration, the default minimum limits apply for that procurement.

5.2 Stored procedures and callable routines (SQL/PSM)

An emerging new part of the SQL standard for Persistent Stored Modules (SQL/PSM) was registered as an ISO/IEC Committee Draft (CD) in March 1994 (see [11]). Although this specification will not reach formal standardization until at least late 1995 or early 1996, it should be sufficiently complete and stable to justify its careful use in procurements before that date. The intent of SQL/PSM is to make SQL a computationally complete programming language with variables, procedures, functions, and flow-of-control statements. In particular, packages of SQL procedures (i.e., modules) may be stored at server nodes in a communications network with only a procedure call needed to invoke a desired action. The advantage is that modules may be stored persistently in the database, subject to SQL access control and integrity management, thereby allowing a reduction of comunications overhead along with optimization and other performance efficiencies at the server site.

A major advantage of the SQL/PSM is that non-SQL data managers will be able to present their special features to applications in an SQL environment as callable SQL functions or procedures. The only requirement is that the calling syntax be standard SQL syntax as far as the calling application is concerned and that the parameters be defined as SQL data types. The content body of the functions and procedures may not be visible to the end user and thus may be implementation-dependent. The SQL/ERI Server can use the SQL Information Schema catalog tables to make known to the users exactly which functions and procedures are available for their use. The "signature" of such routines will also be available from the Information Schema.

5.3 SQL multimedia class library (SQL/MM)

A new ISO/IEC international standardization project for development of an SQL class library for multimedia applications was approved in early 1993. This new standardization activity, named SQL Multimedia (SQL/MM), will specify packages of SQL abstract data type (ADT) definitions using the facilities for ADT specification and invocation provided in the emerging SQL3 specification [12]. SQL/MM intends to standardize class libraries for science and engineering, full-text and document processing, and methods for the management of multimedia objects such as image, sound, animation, music, and video. It will likely provide an SQL language binding for multimedia objects defined by other JTC1 standardization bodies (e.g. SC18 for documents, SC24 for images, and SC29 for photographs and motion pictures).

The project plan for SQL/MM indicates that it will be a multi-part standard consisting of an evolving number of parts. Part 1 will be a Framework that specifies how the other parts are to be constructed. Each of the other parts will be devoted to a specific SQL application package. Even though this project is just getting started, initial base documents exist for Part 1: Framework, Part 2: Full Text, Part 3: Spatial, and Part 4: General Purpose Facilities (see [13]). As the different components of the SQL/MM specification reach CD and DIS stability, an SQL/ERI Server could claim support for specific features.

5.4 Abstract data types and methods

The emerging SQL3 specification contains a number of data abstraction facilities, including user-defined data types and methods. For example, see Clauses 4.11, "Abstract data types", 11.47, "", and 11.48, "", of the August, 1994, version of [12]. If data abstraction is an inherent requirement of an SQL/ERI Server, then it could define its Abstract Data Types and make them available to SQL applications using these definitional mechanisms. As the data abstraction facilities of the SQL3 specification reach CD and DIS stability, an SQL/ERI Server could use them with more confidence to permanently define its abstract data types and methods.

A major advantage of these ADT features combined with the SQL/PSM identified above is that non-SQL data managers will be able to present their application-specific ADTs to applications in an SQL environment. The signature of such ADTs would be available in the Information Schema provided by each SQL/ERI Server, and the special methods on each ADT would be callable as SQL functions or procedures. The only requirement is that the calling syntax be standard SQL syntax as far as the calling application is concerned and that the parameters be SQL data types or known ADT types provided by the SQL/ERI Server. The abstract data type body of usable ADTs may not be visible to the end user and thus may be implementation-dependent. The SQL/ERI Server can use the SQL Information Schema catalog tables to make known to the users exactly which ADTs and associated methods are available for their use.

5.5 Object data management

The emerging SQL3 specification contains facilities for defining and referencing object identifiers. For example, see Clauses 4.10 "Object identifier", 11.48 "" WITH OID option, and 6.12 "", of the August, 1994, version of [12]. If object identity is an inherent requirement of an SQL/ERI Server, then it could define its Abstract Data Types with Object Identifiers (OID) and make them available to SQL applications using these definitional mechanisms. In this manner, object database management systems and specialized object repositories could make their features and facilities available to an SQL environment. As the different OID facilities of the SQL3 specification reach CD and DIS stability, an object-oriented SQL/ERI Server could use them with more confidence to permanently define its objects and their methods.

5.6 Encompassing transactions

Database Language SQL [8] already supports the notion of an "encompassing transaction", that is, a transaction that may involve resource managers other than a single SQL database system (including possibly non-SQL resource managers) and controlled by some entity other than the SQL database system. Communication between that other entity (usually called a transaction manager) and the resource managers requires a standardized interface, because such products are often required to participate in the same global transaction even though they are purchased from different vendors at different times and may be operating at different nodes in a communications network. In this more global transaction processing environment, the encompassing transaction will be initiated and terminated by that other agent, which interacts with the SQL environment via an interface that may be different from SQL COMMIT and ROLLBACK statements.

The X/Open Company, Ltd., has defined an application program interface (API), called the "XA interface", to coordinate the activities of resource managers (RM) and transaction managers (TM). This interface has two components, called the xa_component and the ax_component. The xa_component is to be used by TMs to influence the actions of RMs, whereas the ax_component is to be used by RMs to communicate with the TMs. The XA-interface, as defined by X/Open, specifies an API for the ISO Distributed Transaction Processing (DTP) standard (ISO/IEC 10026:1992), which itself only specifies services and protocols. ISO has not yet published any APIs for this standard, or for other related OSI standards, although there is a study group in ISO/IEC JTC1/SC21 to examine the API question. The XA-interface was published by the X/Open Company, Ltd., in 1991 and 1992 as a "Common Application Environment" specification, which is intended to be completely stable. X/Open has continued work on their DTP specifications and a follow-on enhancement, informally called XA2, is in development; however, XA2 is expected to be completely compatible with the existing XA specification, while adding additional facilities.

A number of SQL resource managers are also beginning to claim conformance to the xa_component of the XA-interface. In recognition of this trend, both ANSI and ISO/IEC approved new SQL standardization projects in 1994 that will lead to formal standardization of an SQL Specialization of the X/Open XA-interface as an ANSI/ISO/IEC International Standard. These projects are just getting started, but the base document is derived from and completely compatible with the existing X/Open specification, and the project description requires that it retain this compatibility during development. The following functions are defined as part of the xa-component: xa_close, xa_commit, xa_complete, xa_end, xa_forget, xa_open, xa_prepare, xa_recover, xa_rollback, and xa_start. The resulting International Standard for the SQL/XA Interface will be a specialization of these functions for SQL resource managers that retains existing syntax and intended semantics, but may refine the details of how SQL resource managers shall respond to xa-routines in terms of existing SQL transaction semantics.

The XA-interface is intended only for calls from a global transaction manager to various resource managers. It is not intended for normal use by end-user application programs. Instead, application programs should use interfaces designed for communications between the application program and the global transaction manager. For this reason, procurements should be very careful how they specify requirements for encompassing transactions; it may be a requirement that SQL/ERI Servers be able to process two-phase commit requests, and thereby participate as resource managers in a global transaction under the direction of a global transaction manager, but it may not be a requirement that an end-user application program be able to communicate directly with such a resource manager using xa-routines.