Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Data computers-data descriptions and access language (RFC0195)

IP.com Disclosure Number: IPCOM000004881D
Original Publication Date: 1971-Jul-16
Included in the Prior Art Database: 2001-Jul-11
Document File: 5 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

G.H. Mealy: AUTHOR

Abstract

machine. This language should have (at least) the following features:

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 39% of the total text.

Network Working Group G. H. Mealy Request for Comments: 195 HARV NIC 7140 16 July, 1971 Categories: D.4, D.7

Data Computers Data Descriptions and Access Language

According to the minutes of the NWG meeting in May (RFC 164), it appears that a unified approach to Network data management is being proposed to CCA. The purpose of this paper is to discuss some of the problems involved and to suggest possible avenues of approach toward their resolution. Parenthetically, I believe that a non-unified approach leads to even worse problems.

My main remarks are predicated on a few assumptions and their consequences. Since some or all may turn out to be wrong, it seems appropriate to state them explicitly. The steps in the arguments leading from the assumptions to their consequences may appear to be (and in fact may be) less than obvious. They are all of a piece, however, and revolve around the necessity for doing business with a number of dissimilar HOST systems while attempting to make it unnecessary for an individual user or user program to know the details of data file organization and representation. Given this as an objective, I believe that the arguments are quite direct.

Assumptions

1. We face the usual set of naming, cataloging, protection,

backup, etc. problems.

(I say this only to dismiss the subject as far as the following is concerned. In my estimation, these problems and feasible solutions are reasonably well understood; our real problem in this area is in reaching agreement on specifics while leaving sufficient ratholes for future expansion).

2. Files stored will contain arbitrarily complex data objects.

3. The organization of any file (that is, the way its structure is mapped into physical storage by the data computer) will normally be unknown by the user.

Healy [Page 1]

RFC 195 Data Computers July 1971

4. Data items in files may be stored in arbitrary representations (e.g., those of the originating user's HOST rather than that of the data computer or other "standard" representation).

5. Access to a file will normally be to some subset of it. (I.e., the unit for transmission will usually be part of a file rather than the whole file, and access will not necessarily be sequential).

Consequences

1. A method of data description significantly more powerful than now commonly available (as with COBOL or PL/I) is required. The descriptions must be stored with the files. Data item representations and storage organizations must be describable.

2. The data computer must offer a "data reconfiguration service",

based on use of the data descriptions.

3. A representation and organization-independent level of

discourse must be made available for controlling access.

Data Description

As it happens, the descriptive facilities in ELl (References 1 and 2) are almost adequate as they stand. ELl is an e...