![[CoOL]](/icons/sm_cool.gif){kind=icon}
for the Development and Implementation of Standards for the Creation, Transfer, Access, and Long-Term Storage of Electronic Records of the Federal Government
National Archives Technical Information Paper No. 8Strategy for an Evolving Standards Environment
Standards Implementors Workshops
Standards and Life Cycle System Design
Since becoming Archivist of the United States, one of my top priorities has been to revitalize the electronic records programs of the National Archives. In 1988, I established the Center for Electronic Records and initiated projects to identify the critical issues that electronic records pose for Federal agencies, the National Archives, and the archival community at large. Clearly, hardware and software dependence has been and continues to be one of these critical issues. In the opinion of NARA experts, the ideal solution for this issue would be to preserve electronic records of permanent value without their being dependent upon a specific computer for processing or on specific computer programs for understanding and use.
Several years ago a wide-spread concern over the incompatibilities between different computer systems gave rise to an international effort to achieve connectivity between incompatible computer systems by developing and implementing international standards. Called the Open Systems Interconnection Reference Model (OSI), this effort seemed to offer a cost- effective vehicle for achieving portability of electronic records, an issue of great concern to the archives and records management communities.
To bring this issue into focus, the National Archives and Records Administration contracted with the National Bureau of Standards (now known as the National Institute of Standards and Technology) to investigate the role of standards in the creation, processing, storage, access, and preservation of electronic records. Last year, NIST delivered a report to the National Archives on its findings and recommendations. Although the report recognizes that the National Archives faces numerous difficulties with existing electronic records, its more than 100 recommendations focus largely upon the future. In order to address more immediate needs and based upon information in the NIST Report, the National Archives has developed its own short- term strategy for dealing with issues of records management and archival standards for electronic records over the next several years.
This Technical Information Paper delineates the approach the National Archives will take over the next several years. While this Technical Information Paper draws heavily from the NIST study, the approach the National Archives takes reflects both the complexity and ambiguity inherent in the development and adoption of standards for electronic records management and archives.
The National Archives will undertake several important activities that support the development and use of standards for electronic records management and archives. These activities include evaluation of software products supporting data base and document transfer, identification of the functional requirements for the life cycle management of electronic records, and additional joint activities with the National Institute of Standards and Technology.
A key point implicit in this Technical Information Paper is that the creation, processing, storage, access, and permanent retention of electronic records is not the exclusive concern of the National Archives. To be sure, all three branches of the Federal Government, state and local governments, the user community, and the manufacturers of electronic records management and archives hardware and software must continue to inform themselves and each other of their respective needs and concerns. For this reason, I hope this Technical Information Paper is widely disseminated in the records and information management and archives communities. As these activities unfold, the National Archives will organize periodic briefings on standards and issue updates to this Technical Information Paper. My goal is to share information and to develop a common agenda that serves the needs of the archives and records management communities.
DON W. WILSONIn September 1987, the National Archives and Records Administration contracted with the National Computer Systems Laboratory of the National Institute of Standards and Technology (NIST, formerly the National Bureau of Standards) to evaluate the role of standards in the creation, processing, storage, access, and permanent storage of electronic records. In May of 1989 NIST delivered to the National Archives a report[1] containing more than 100 recommendations, most of which address anticipated future problems of electronic records rather than the known problems of past and present electronic records.
The NIST recommendations to NARA generally can be subsumed under the following:
The National Archives has reviewed these recommendations and has developed an approach that is at variance with many of the NIST recommendations. This approach, which was discussed with the National Archives of Canada (also conducting a similar study), is based upon an assessment that it is premature for NARA to choose specific standards and that NARA should concentrate upon identifying the archival requirements for electronic records and participating in the development of standards that meet these requirements. This Technical Information Paper takes this general assessment into account and identifies specific activities that the National Archives and Records Administration will undertake. These activities will ensure that the National Archives:
The NIST report makes very clear that there is limited software to implement standards relevant to NARA's electronic records management and archives programs. This dearth of software reflects the newness of the standards themselves and the absence of a significant current market demand for the software. Undoubtedly, the Federal Government's adoption of the suite of standards in the Government Open Systems Interconnection Profile (GOSIP) and private industry's emphasis on the use of standards, especially in Europe, will accelerate software development and availability over the next several years.
In the document transfer arena, software tools are currently available in the United States for only one standard - the Standard Generalized Markup Language (SGML)[2] for the electronic transfer of documents, reports, and studies which are intended for publication. SGML, however, does not support compound documents (i.e., those containing textual and non-textual material, such as graphs and images, in the same document) and SGML interfaces to other document transfer standards (Standard Page Definition Language - SPDL[3] or Office Document Architecture/Office Document Interchange Format[4] - ODA/ODIF) are not likely to be available until 1991 - 1992.
There is significant software implementing the electronic mail standard (X.400 or Message Handling Service - MHS), but this standard bears largely on the routing and addressing of electronic mail rather than its content.
The NIST report recommends that NARA adopt Standard Page Definition Language (SPDL) as the primary tool for transferring electronic documents because unlike ASCII code alone, SPDL retains the original form of documents. Unfortunately, SPDL is still in draft form and its future adoption is several years away. Even when SPDL software becomes available, it is unlikely that all agencies will use it or that SPDL formatted documents will meet all archival needs. Therefore, NARA policy for document interchange must address several standards, including SPDL, ODA/ODIF, and SGML.
There is even less software development activity in the complex data base transfer area (relational, hierarchial, and network) even though there is an approved FIPS standard (FIPS Pub 123 also known as Data Description Format - DDF or International Standards Organization 8211) in place. Only one commercial vendor - a small private contractor - has done significant work in this area and there is no overall apparent market push for vendors to develop software. An exception to this generalization is the interest of cartographic users in using DDF.[5] According to the NIST project staff, the primary reason for this absence of a market push for data base transfer standards is that document transfer issues are receiving attention as part of the implementation of electronic mail. No doubt this will change over the next several years as document transfer standard issues are resolved. Nevertheless, it is not clear how quickly Federal agencies with substantial investments in existing data bases and data base software can or will shift to a data base using a standard IRDS.[6] How quickly Federal agencies make this shift can have an enormous impact on the work program of the National Archives.
In the absence of a data base transfer standard, the NIST report recommends that NARA establish a data base transfer policy using IRDS and flat ASCII files. Currently, this recommendation can not be implemented, as no commercial software implementation of the standard IRDS is currently available. NIST has developed a prototype for general testing purposes to evaluate how an IRDS might be used to transfer complex data bases. This software could be used to help evaluate how useful the standard IRDS would be to NARA. Of course, a prototype is not suitable for actual implementation, but now that IRDS is a FIPS publication, it is likely that over the next few years more IRDS based software will become available.
The last general issue to be considered in formulating a NARA strategy for the evolving standards environment is the possibility that some of today's standards will fall into disuse and that new standards surely will emerge. How can NARA best deal with a dynamic standards environment? What mechanisms can be put in place that ensure that the document and data base transfer standards NARA adopts today do not become impediments to tomorrow's standards?
In general, marketplace dynamics - what users require and what vendors provide - determine what standards are developed and how they are implemented. For example, the current market focus is an "open systems" environment in which users require products that make it possible to migrate applications from one system to another, different system. Consequently, in order to remain competitive, computer vendors will develop products for this market. This market can be considered a spectrum in which many new products, some of which may be experimental, are introduced in order to influence emerging market trends or to dominate part of the market. Over a period of time there is a "shaking out" as products with inadequate user bases drop out. The surviving products typically involve considerable user investment so that radical change becomes less likely, thereby providing a measure of stability. These same market forces also come into play in the development and implementation of information technology standards. In some instances, vendors may develop products which exceed standards, leading at times to modifications of standards. This suggests that NARA should avoid experimental information technology products and instead concentrate on those information technology standards with clearly established user bases. In addition, NARA should recognize that even standards with clearly established user bases are likely to undergo change and modification.
This approach does not mean that NARA must avoid all involvement in the development and implementation of information technology standards. NARA can perform the extremely valuable role of identifying and articulating the archival and records management needs of Federal agencies that data exchange standards must address. This function cannot be overemphasized because many of the NIST recommendations presume that NARA and Federal agencies have already defined these needs, when in fact this has not been done on a systematic basis.
Other activities NARA can engage in include encouraging Federal agency use of the standards identified in the NIST report as relevant to archives and records management. Furthermore, as software products for these standards become available, where appropriate NARA might contract with NIST to analyze and study their usability.
NARA will conform to the Government Open Systems Interconnection Profile in the procurement of new hardware and software. Although NARA will study the utility and problems of using various data base and document exchange standards, including use of pilot projects, the primary focus will be upon information technology standards with clearly established user bases. NARA will adopt information technology standards only after actual demonstration of their usability in an archives and records management context. Finally, NARA will work with vendors and user groups in encouraging the adoption of standards and development of software that address archives and records management needs.
The NIST report stresses the need for NARA to adopt a data administration policy that integrates the management and retrieval of information about electronic records as well as the management of the electronic records themselves. Information about electronic records usually consists of information about the system that produced the records, descriptions of the data elements that make up electronic records as well as definitions of the relations among the various data elements. Data elements might also include records disposition instructions, status (draft or final version), and archival descriptive information while relationship definitions might include access permissions and cross-references. When framed within the specifications of the Information Resource Dictionary System (IRDS), this information about electronic records (sometimes referred to as "metadata") provides a powerful tool for maintaining intellectual control of descriptive information in a system independent format.
The concept of a data dictionary is not new. In fact, every complex data base supports some sort of data dictionary, which defines data structures and data definitions. Usually, a data dictionary is in a proprietary form that makes it either system or software dependent. However, the growing use of SQL (Structured Query Language) as a data base language for relational data bases[7] suggests that there is an alternative, at least in the short-run, to IRDS. Several major data base vendors, including Ingres, DB2, and Oracle, among others, currently offer products that conform to the SQL standard. The net effect is to resolve low-level data definition problems and to make possible relatively easy data transfer between conforming SQL relational data base systems.[8]
SQL is a powerful tool for facilitating the portability of relational data bases but it does not offer the robustness of an IRDS, especially in terms of potential evidential value archivists and researchers may be interested in capturing in data base applications. SQL focuses upon only one dimension of complex data bases - relational data bases - and a SQL data dictionary typically defines only the data structures of tables. IRDS as it is presently conceived is not limited to any single kind of data base application nor to data structures of tables. In fact, IRDS seems ideally suited for a wide range of metadata structures that generally fall under the archival headings of documentation and finding aids.
As Federal agencies increasingly rely upon SQL for portability of data base applications (queries and data), it is likely that SQL will become a de facto data transfer standard for relational data bases. During this same period of time, software implementations of IRDS are likely to emerge that potentially could provide both to Federal agencies and to NARA powerful tools for describing the systems context of electronic records as well as the records themselves.
A major obstacle to implementing an IRDS data administration approach is the absence of IRDS software conforming to the standard, although several firms have indicated they are developing products.[9] As noted earlier, NIST has developed limited prototype IRDS software that can be used for testing. The prototype software has substantial limitations, however, and its utility would be largely limited to proof of concept testing.
NARA implementation of an IRDS data administration policy has major implications for the Center for Electronic Records' efforts to develop a single, coherent system for dealing with accessioned electronic data files. If IRDS emerges as a widely implemented and robust standard that satisfies archival requirements for description and control of accessioned electronic records and NARA implements an IRDS data administration policy, the Center for Electronic Records would have to migrate from the system being developed to one that is IRDS driven.
The data administration policy that NIST recommends also would require agencies to generate IRDSs that can be transferred and integrated into the NARA IRDS (or multiple IRDSs). Although the IRDS standard appears sufficiently flexible to serve both programmatic and long-term storage and retrieval needs, this is uncharted area and it is unclear exactly how this would work in practice. Even more to the point, mandating use of an IRDS to transfer electronic records could be counter-productive for agencies who currently use SQL conforming data bases.
In keeping with the general policy of endorsing information technology standards for archives and records management only where this is an established user base, NARA will not at this time adopt an IRDS based data administration policy. As software become available, NARA will evaluate the capabilities of IRDS products to meet the program needs for accessioned electronic records in order to become familiar with practical IRDS issues and possible limitations of the standard. NARA will continue to support a comprehensive system for the transfer and management of data files and data bases. Periodic reports that evaluate this effort will be issued.
As noted previously, the NIST study concluded that no single data base transfer standard now exists. The report recommends that until such a standard is available NARA should use a combination of SQL, IRDS, and ASCII files to transfer and store data bases. The NIST consultants are confident that any new standard that evolves will accommodate IRDS, SQL, and ASCII. SQL and ASCII are established standards which have been implemented. IRDS, of course, has not been implemented. Hence, until standard IRDS products become widely available, it is very important that NARA gain hands-on experience by conducting pilot data base transfers with Federal agencies using SQL and/or prototype IRDS software.
The NIST study acknowledges that in the absence of IRDS implementations and a single data base transfer standard, NARA must develop a short-term policy. This policy, the NIST consultants maintain, should focus upon data base systems in common use among most Federal agencies. Consequently, the report recommends that NARA conduct a survey of Federal agencies to identify the most common data base systems in use that maintain records of permanent value. These survey findings could be used to support the development of a comprehensive system for transfer and management of data files and data bases.
Development of a unified data base transfer standard is not likely for at least ten years, largely because it takes from three to five years to secure approval after a draft has been prepared, and there is little apparent interest among users or vendors that is likely to lead to a draft standard over the next five years or so. Nevertheless, NARA could work with NIST in promoting an awareness for the need of generalized software tools to support a long-term data base transfer policy.
At this time NARA will not endorse either IRDS or SQL as the preferred data base transfer standard. Rather, NARA will conduct pilot transfers of complex data bases. NARA will monitor developments with IRDS software, and as it becomes available, will perform "hands on" experiments in data base transfer. NARA will work with NIST in promoting an awareness of the need for generalized software tools to support a long-term data transfer policy. This could include establishment of a NARA/NIST sponsored forum in which the views and concerns of Federal agencies regarding data base transfer issues could be articulated.[10] Recommendations could be presented to the American National Standards Institute (ANSI).
Although there are multiple standards in place or in draft form for document transfer, the NIST report nonetheless recommends that NARA advocate the use of SGML to create documents and the use of SPDL to transfer documents of permanent value to the archives. Of course, SPDL is not yet a standard and some knowledgeable observers think it will be several years before it is adopted as a standard. Given this uncertainty, it is premature for NARA to recommend its use government-wide to transfer documents.
One other point worth noting in passing is that the NIST report assumes that in all cases NARA would want to transfer and store the original representation of electronic documents. Certainly, in many instances this would be the case. In other instances, preservation of the informational content would be sufficient. In some instances, both might be required. However, neither NARA nor Federal agencies have adequately defined and articulated when it is important for archives and records management to have the original representation of documents, when it is sufficient to have the informational content of these documents, and when both are necessary. When it is necessary to retain the original presentation of documents, SPDL is useful because it is difficult to alter a document without leaving evidence of the change.
In contrast to SPDL, SGML is an established standard with several software implementations now available. Most of these implementations, however, support the transfer of material intended to be printed. In this instance, of course, SGML encoded reports could be accessioned. In contrast, the Department of Defense has developed the Computer-Assisted Acquisition Logistics System (CALS) which uses SGML for technical report transfer and eventually for document transfer.
Despite the growing use of SGML, it is unclear exactly how SGML would be used in a document creation environment. Equally important, it is unlikely that NARA could impose a single document creation/transfer standard on Federal agencies with diverse mission requirements. Nor is it likely that GOSIP will invoke a single standard in this arena.[11] This suggests that NARA should work with NIST in ensuring that there are records management and archives components included in implementations of GOSIP based document creation/transfer standards.
Document transfer standards are generic in nature and do not address specific implementation issues. Consequently, a major problem underlying document transfer standards is the absence of clear records management and archival functional specifications for the life cycle management of information in an electronic environment. For example, as noted earlier, NARA and Federal agencies need to articulate when an electronic representation of an original page image is required or when the informational content from that page image is sufficient. In order to ensure that these functional specifications meet the needs of the workplace, input into them must come from the creators and users of electronic documents. It is important, therefore, that NARA work with Federal agency records managers, information resource managers, researchers, and other key groups in defining these functional specifications.
NARA will not endorse SGML for use in creating electronic documents nor SPDL as the preferred standard for electronic document transfer at this time. Rather, NARA will continue to monitor the development of standards for document transfer, and, as software becomes available, to conduct pilot projects. Findings from these pilot projects will be used to help formulate a document transfer policy.
NARA will investigate applications now underway that offer document transfer capability. Specifically, NARA will explore the possibility of participating in the development of the Department of Defense Computer-assisted Acquisition Logistics Systems (CALS), which employs SGML. Although CALS does include a functionality that could include records management, no development work is currently underway. NARA will offer to work with the CALS developers in identifying what comprises this records management component and to assist in testing any software implementation.
NARA will establish an inter-agency working group, including representatives from professional societies to identify the archives and records management functional specifications for the life cycle management of electronic documents. NARA will use these specifications in developing guidelines for Federal agencies that might be published as NARA regulations or as a Federal Information Processing Standard (FIPS). Other non- Federal organizations may also find these specifications useful in establishing guidelines for the life cycle management of electronic documents.
The process whereby ANSI standards are developed, approved, and revised involves ANSI Accredited Standards Committees and their subordinate Technical Committees where most of the work is conducted. Technical Committees usually comprise vendor representatives, users from interested organizations, and representatives of what are called general interest groups. Typically, there is a great deal of informal communication and exchange of views between the three-times-a-year meetings of the Technical Committees. Because standards development is a consensus building process that the balloting confirms, efforts are made to accommodate conflicting viewpoints. As noted earlier, generally this process may take several years.
American national standards development work that is directly related to electronic records involves primarily two Technical Committees of Accredited Standards Committee X3, Information Processing Systems; specifically, Technical Committee X3H4, Information Resource Dictionary which deals with the IRDS standard; and X3V1, Text: Office and Publishing Systems, which deals with Text and Office Systems. The latter includes SGML, SPDL, and ODA among other issues. There is another ANSI Accredited Standards Committee - Z39, Libraries, Information Systems, Publishing - which deals with issues (e.g., electronic interchange of bibliographic information) that relate indirectly to electronic records. If the archives and records management communities hope to ensure that standards address long-term information management concerns, then the best forum for this activity is participation in the technical committees. It is far easier to help shape a standard while it is under development than afterwards. Thus, NARA's full participation[12] in the Technical Committees, X3H4 and X3V1 and monitoring the Z39 Technical Committee work[13] could be useful, both to the National Archives and the larger archives and records management communities.
NARA will become a regular participant in the X3H4 and X3V1 working groups. In addition, NARA will monitor work plans and reports of the Z39 Technical Panel as they relate to document and data base transfer issues. NARA will issue periodic status reports to interested parties.
A standard can be thought of as a collection of tools to solve a set of related problems. Each standard usually has more tools than any one user or subset of users is likely to need. Furthermore, some of the tools are optional, and some are mandatory. Standards implementor workshops establish broad functionality requirements[14] of user communities and propose appropriate modules to meet these requirements. Usually, optional modules that offer enhanced features also are proposed.
NIST is charged with the responsibility for organizing an implementors workshop for each OSI/GOSIP standard. Participants in implementors workshops, which usually include hardware and software vendors and representatives of organizations that plan to use a standard, propose how each standard can or should be implemented. NIST provides a secretariat which convenes formal meetings for each implementors workshop. Usually, there is a great deal of informal communication and exchange of views that occurs between quarterly meetings and may involve as much as four or five days per month of a workshop participant's time.
It is far easier and more productive to shape the implementation of a standard while it is still in the implementors' workshop stage than to modify implementors workshop guidelines and rules after they have been adopted. Therefore, NARA will ensure that archives and records management concerns are represented in the OSI implementors workshops.
NARA will work closely with NIST in identifying which implementors workshops are most critical for NARA's electronic records programs. When other implementor workshops deal with issues of concern to NARA, NIST will be asked to bring these concerns to the attention of the workshops.
Implicit in many of the NIST recommendations is the notion that life cycle information management and related standards and regulatory concerns must be considered at the time of system design. This reflects a widely held view that an archives and records management component (standards, regulations, and guidelines) should be formally incorporated into life cycle systems design and included in the Federal Information Process Standards (FIPS) Publication 101, which covers life cycle system design. This particular topic was discussed at some length at the Easton Conference on "Electronic Records: A Strategic Plan for the 1990s"[15], and in fact one working group proposed that this become a major NARA initiative. This focus is also a concern of several state archives programs.
There is a broader context in which implementing archives and records management regulations into life cycle systems design must be considered. The Federal Information Resources Management Regulation (FIRMR) requires that records management concerns be addressed in the system design stage. However, guidelines for Federal agency use have not been developed. NARA recognizes the need for additional guidance in this area.
NARA will take the lead in developing these guidelines through the inter-agency working group on functional requirements for electronic records management and archives (see page 16) which will identify the critical areas in the FIPS Life Cycle Systems Design where specific standards, regulations, and guidelines for archives and records management could be incorporated. Based upon the recommendations of this working group, NARA will issue guidelines in a NARA Bulletin and will request that NIST incorporate the guidelines into the existing FIPS on Life Cycle Systems Design. Other non-Federal organizations could adopt these guidelines or use the recommendations to develop their own guidelines
Many of the issues discussed in the NIST report and this Technical Information Paper cut across individual NARA Office programs and responsibilities. It is unlikely that adequate resolution of these issues as well as full achievement of the various NARA Actions can occur without substantial participation of all appropriate NARA Offices integrating the proposed NARA strategy into various Office programs. Achieving this integration helps to ensure that appropriate NARA Offices fully utilize the full range of new information technologies. Through NARA-wide coordination of the guidelines, standards, and policies developed for electronic records, NARA will enhance its ability to derive solutions to the full range of archival and records management problems posed by electronic records.
To be sure, the issues of data administration policy and data base and document transfer standards for electronic records extend far beyond internal NARA concerns. Other Federal agencies, state agencies, and the research community will be affected or influenced by NARA's policies, actions, and guidelines. It is important that they too both understand and support NARA's activities and priorities regarding a policy and standards for electronic document and data base transfer. In order to promote this understanding and support, NARA must share information, must seek the opinions and ideas of those not directly involved in the activities described in this strategy, and must remain flexible in responding to newly emerging developments that this strategy may not presently contemplate. On the other hand, such a program should scrupulously avoid presenting a policy and standards as panaceas or as "easy" solutions. There is a great deal that NARA must learn before attempting to provide comprehensive guidance. Over the first year or so, this program, therefore, must focus primarily on information sharing.
The Archivist will establish a NARA working group composed of representatives from appropriate NARA Offices to coordinate the implementation of the various activities as well as related initiatives involving electronic records described in this Technical Information Paper. This working group will periodically report to the Archivist and the Offices on its progress.
In order to share NARA's plans and activities with the broader archives, records management, and user communities, NARA will periodically report to them on its progress. In addition, from time to time NARA will organize special meetings and briefings to share information about its plans and priorities with such organizations as the Society of American Archivists, the National Association of Government Administrators and Archivists, and the Association of Records Managers and Administrators.
1. Framework and Policy Recommendations for the Exchange and Preservation of Electronic Records (National Computer Systems Laboratory of the National Institute of Standards and Technology, 1989).
2. For a description of SGML see Framework and Policy Recommendations for the Exchange and Preservation of Electronic Records (hereafter referred to as Framework), Attachment C: Recommendations for Document Transfer Standards and Their Integration into National Archives Policy, pp. 11 - 13, 24 - 25.
3. Framework, pp. 13 - 14, 25 - 26.
4. Framework, pp. 12- 13 and 20 - 25.
5. The Standards Working Group of the Federal Interagency Committee on Digital Cartography is looking at DDF. NARA has a representative on the Committee and the Working Group.
6. This is particularly true with the data dictionary functionality embedded in Structured Query Language (SQL), which is rapidly becoming a de facto standard for transferring relational databases from one computer system to a different one.
This topic is discussed in greater detail on page 10.
7. SQL is an ANSI and ISO standard. In addition, for the Federal Government it is a Federal Information Processing Standard (FIPS). For further discussion of SQL, see Framework, pp. 24 - 27.
8. For efficiency, SQL systems store data in a proprietary format. Most SQL systems have output formats, such as ASCII or ASN.1, that allow relatively easy data interchange. However, data in these output formats may require "normalization" before they can be processed.
9. IBM, Honeywell, Manager Software Products, and Pansophic Systems have announced their intention to support the ANSI IRDS standard. Pansophic Systems is marketing a service interface with their software that provides an IRDS functionality. It is not, however, a stand alone IRDS.
10. This forum could be patterned after the highly successful Digital Image Applications Group (DIAG).
11. The current version of GOSIP includes ODA/ODIF but SGML is not part of the profile.
12. Full participation means attending most of the three-times- a-year meetings and exchanging written comments about various proposals. The process of standards development is such that without substantial, continuing participation it is unlikely that NARA concerns and views would receive serious attention by committees.
13. NARA is a member of Z39 but so far NARA has been largely interested in paper and storage environment concerns.
14. The following example illustrates this point. The ODA/ODIF standard has a read function but it does not specify how this function is carried out. For English documents reading occurs from left to right. However, a read function for Arabic documents would specify from right to left.
15. This conference was held in Easton, Maryland in June 1990 under the sponsorship of NARA's Office of Records Administration.