RFC195 日本語訳

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

コメントを求めるワーキンググループのG.のH.の粉だらけの要求をネットワークでつないでください: 195 HARV NIC7140 16 7月、1971のカテゴリ: 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.

5月(RFC164)のNWGミーティングの議事録によると、Networkデータ管理への統一されたアプローチがCCAに提案されているように見えます。 この紙の目的は、かかわった問題のいくつかについて議論して、彼らの解決に向かったアプローチの可能な大通りを示すことです。 挿入的に、私は、非統一されたアプローチがさらに悪い問題を引き起こすと信じています。

   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.

私の主な所見はいくつかの仮定とそれらの結果で叙述されます。 いくつかかすべてが間違っていると判明するかもしれないので、明らかにそれらを述べるのは適切に思えます。 仮定からそれらの結果まで導く議論における階段は明白であるというよりも(そして、事実上、あるかもしれません)以下であるように見えるかもしれません。 個々のユーザかユーザ・プログラムがデータファイル組織と表現の詳細を知るのを不要にするのを試みている間、彼らは、しかしながら、1片のすべてであり、多くの異なったHOSTシステムとビジネスをする必要性を中心題目とします。 目的としてのこれを考えて、私は、議論がかなりダイレクトであると信じています。

   Assumptions
   ------------

仮定------------

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

1. 私たちは普通のセットの命名、カタログに載せる保護、バックアップなど問題に直面しています。

         (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.

2. 保存されたファイルは任意に複雑なデータ・オブジェクトを入れてあるでしょう。

      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.

3. 通常、どんなファイル(すなわち、構造がデータコンピュータによって物理的なストレージに写像される方法)の組織もユーザで未知になるでしょう。

Healy                                                           [Page 1]

RFC 195                      Data Computers                    July 1971

ヒーリー[1ページ]RFC195データコンピュータ1971年7月

      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).

4. ファイルのデータ項目は任意の表現(例えば、データコンピュータか他の「標準」の表現のものよりむしろ起因しているユーザのHOSTのもの)で保存されるかもしれません。

      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).

5. 通常、それの何らかの部分集合にはファイルへのアクセスがあるでしょう。 (通常、トランスミッションのためのすなわち、ユニットは全体のファイルよりむしろファイルの一部になるでしょう、そして、アクセスは必ず連続するというわけではないでしょう。)

   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.

1. 現在一般的に利用可能であるより(COBOLやPL/Iのように)かなり強力なデータ記述のメソッドが必要です。 ファイルで記述を保存しなければなりません。 データ項目表現とストレージ組織は説明可能であるに違いありません。

      2. The data computer must offer a "data reconfiguration service",
         based on use of the data descriptions.

2. データコンピュータはデータ記述の使用に基づいて「データ再構成サービス」を提供しなければなりません。

      3. A representation and organization-independent level of
         discourse must be made available for controlling access.

3. 表現と組織から独立しているレベルに関する会話をアクセサリーを制御するのに利用可能にしなければなりません。

   Data Description
   -----------------

データ記述-----------------

   As it happens, the descriptive facilities in ELl (References 1 and 2)
   are almost adequate as they stand.  ELl is an extensible language --
   the compiler and interpreter for ELl are principal components of a
   system implemented on the PDP-lO at Harvard -- which allows the
   definition of arbitrary data structures in terms of a few primitive
   data types (BOOL, CHAR, INT, REAL, SYMBOL, MODE, FORM, and ROUTINE).
   These data types are of the sort I called "generic" in Reference 3.
   To the EL1 implementation on the PDP-10, say, we would have to add
   methods to describe a specific representation of INT, etc. and
   primitive routines to convert between specific representations.

たまたま、立つとき、ELl(参照1と2)の描写的である施設はほとんど適切です。 ELlはELlのコンパイラとインタプリタがハーバードのPDP-lOで導入されるシステムの主成分であるという数人の基本データ型(ブール、CHAR、INT、レアル、SYMBOL、MODE、FORM、およびROUTINE)で任意のデータ構造の定義を許す広げることができる言語です。 これらのデータ型は私がReference3に「ジェネリック」と呼んだ種類のものです。 たとえば、PDP-10の上のEL1実装に、私たちは特定の表現の間で変換するためにINT、など、および原始のルーチンの特定の上演について説明するメソッドを加えなければならないでしょう。

   In the ECL system (in which EL1 is embedded), there is no rigid
   distinction between compile time and run time.  In particular, if the
   arguments and free variables of a routine are evaluable at compile
   time, then the routine is evaluated and the value replaces the call.
   More generally, arbitrarily large amounts of a routine being compiled
   may collapse into values.  As far as the data computer is concerned,
   this offers the possibility of producing tailor-made data
   reconfiguration programs, taking maximum advantage of the data
   descriptions at compile time rather than using a strictly
   interpretative mode of operation.

ECLシステム(EL1が埋め込まれている)には、コンパイル時とランタイムの間には、厳密な区別が全くありません。 ルーチンの議論と自由変項がコンパイル時にevaluableであるなら、特に、ルーチンは評価されます、そして、値は呼び出しを取り替えます。 コンパイルされるルーチンの一般に、そして、任意に多く以上の量は値まで崩れるかもしれません。 データコンピュータに関する限り、これはオーダーメイドのデータ再構成プログラムを作り出す可能性を提供します、コンパイル時に操作の厳密に説明的なモードを使用するよりむしろデータ記述の最大の利点を活用して。

Healy                                                           [Page 2]

RFC 195                      Data Computers                    July 1971

ヒーリー[2ページ]RFC195データコンピュータ1971年7月

   Access Language
   ---------------

アクセス言語---------------

   Here, I am on less firm ground.  I will suggest, however, that some
   of the ideas of Sattley, et al (Reference 4) deserve consideration.
   I will quote from the Reference:

ここに、私は、より少ない大地にいます。 しかしながら、私は、Sattleyの考えのいくつかであり、他(参照4)が考慮に値することを提案するつもりです。 私はReferenceから引用するつもりです:

   "... Our proposal is a language for describing the transferable
   features of files, in which conventional programming languages (e.g.,
   FORTRAN, ALGOL, etc.,) can be embedded, and from which the
   information necessary to optimize the use of secondary storage can be
   easily abstracted.  This language defines our abstract model of
   secondary storage in the same way that FORTRAN defined an abstract
   machine.  This language should have (at least) the following
   features:

"... 私たちの提案はファイルの移転可能な特徴について説明するための言語です、埋め込むことができて、補助記憶装置の使用を最適化するのに必要な情報がどれであるかもしれないかから容易に抜き取られたどの従来のプログラミング言語(例えば、FORTRAN、ALGOLなど)で。 この言語はそのFORTRANが抽象計算機を定義した同じようで私たちの補助記憶装置の抽象モデルを定義します。 この言語には、(少なくとも)以下の特徴があるべきです:

      1. File declarations name the file and the elements in the file,
         and specify the range of forms that the elements can take.
         Each file has precisely one named element.  Each file includes
         the (maximum) size (in number of elements) of the file.

1. ファイル宣言は、ファイルでファイルと要素を命名して、要素が取ることができる形の範囲を指定します。 各ファイルには、正確に1つの命名された要素があります。 各ファイルはファイルの(最大)のサイズ(要素の数における)を含んでいます。

      2. Subsets of files can be created by means of grouping
         declarations.  Such subsets can be nested.

2. 宣言を分類することによってファイルの部分集合を作成できます。 そのような部分集合を入れ子にすることができます。

      3. Subsets of files can be named by means of naming declarations.
         Such declarations can also name individual elements of the
         file.  Some form of implicit naming, allowing language
         constructs such as GET ANOTHER TRIPLE, is included.

3. 宣言を命名することによってファイルの部分集合を命名できます。 また、そのような宣言はファイルの個々の原理を命名できます。 GET ANOTHER TRIPLEなどの言語構築を許容して、何らかの形式の暗黙の命名は含まれています。

      4. Members of a set (i.e., elements in a subset or file, subsets
         in a containing subset or file) can be ordered by order
         declarations.  Some form of arbitrary but fixed ordering,
         allowing language constructs such as GET NEXT TRIPLE, is
         included.

4. オーダー宣言で1セット(すなわち、部分集合かファイルの要素、含んでいる部分集合かファイルの部分集合)のメンバーを命令することができます。 GET NEXT TRIPLEなどの言語構築を許容して、何らかのフォームの任意の、しかし、固定された注文は含まれています。

      5. The portions of a file transacted with at a point of access is
         declared.  The size of this portion can be expressed in
         absolute or relative terms.

5. 商取引されたファイルがアクセスのポイントで分配される、宣言されます。 絶対の、または、相対的な用語でこの部分のサイズを表すことができます。

      6. At each point of access to secondary storage, an environment is
         described (or referenced) which contains those declarations of
         types (l)-(5) necessary to define the transaction with
         secondary.

6. 補助記憶装置への各ポイントのアクセスでは、環境は説明されます(タイプ(l)のそれらの宣言を含んでいます)(または、参照をつけられます)--セカンダリでトランザクションを定義するのに必要な(5)。

Healy                                                           [Page 3]

RFC 195                      Data Computers                    July 1971

ヒーリー[3ページ]RFC195データコンピュータ1971年7月

   A language with the above features makes no mention of hardware
   devices, but it provides the programmer with the means of defining
   the algorithm-dependent features of his files so that those files
   might be transferred efficiently from machine to machine".

「上記の特徴がある言語はハードウェアデバイスについて言及しませんが、マシンからマシンまで効率的にそれらのファイルを移すことができるように彼のファイルのアルゴリズム依存する特徴を定義する手段をプログラマに提供します。」

   In the Sattley, et al study, the notion was that a compiler would
   take the source program and actually compile the hardware-dependent
   file accessing code.  In our environment, we are concerned with
   control commands to the data computer (e.g., GET NEXT WALDO) and
   supplying the data computer with enough information to define a
   WALDO.  The basic functions would seem to be the same, in either
   case, albeit implemented rather differently.

Sattleyでは、他は研究して、概念はコンパイラが原始プログラムを取って、実際にコードにアクセスするハードウェア依存するファイルをコンパイルするだろうということでした。 環境で、私たちは、データコンピュータ(例えば、GET NEXT WALDO)への制御コマンドに関係があって、ウォールドーを定義できるくらいの情報をデータコンピュータに供給しています。 かなり異なって実装されますが、基本機能はどちらかの場合で同じであるように思えるでしょう。

References

参照

   1.  Wegbreit, B. The Treatment of Data Types in EL1.  Technical
       Report, Division of Engineering and Applied Physics, Harvard
       University, Cambridge, Massachusetts, May 1971.

1. B. Wegbreit、EL1でのデータ型の処理。 技術報告書と工学の区画と応用物理学、ハーバード大学、ケンブリッジ、マサチューセッツは1971がそうするかもしれません。

   2.  Wegbreit, B. The ECL Programming System.  Technical Report,
       Division of Engineering and Applied Physics, Harvard University,
       Cambridge, Massachusetts, April 1971.

2. B. Wegbreit、ECLプログラミング・システム。 技術報告書と工学の区画と応用物理学、ハーバード大学、ケンブリッジ(マサチューセッツ)1971年4月。

   3.  Mealy, G. H. Another Look at Data.  AFIPS Conference Proceedings,
       vol. 31, 1967 Fall Joint Computer Conference

3. 粉だらけであることで、G. H. 別のものはデータを見ます。 AFIPSコンファレンスProceedings、vol.31、1967フォール・ジョイント・コンピュータ協議会

   4.  Sattley, K., Millstein, R. and Warshall, S. On Program
       Transferability.  Report CA-7011-2411, Massachusetts Computer
       Associates, Wakefield, Massachusetts, Movember 1970.

4. プログラム転々流通性のSattleyとK.とMillsteinとR.とWarshall、S.。 ウェークフィールド(マサチューセッツ)Movember1970、カリフォルニア-7011-2411、マサチューセッツコンピュータ・アソシエイツを報告してください。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Larry Masinter 10/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ラリーMasinter10/99によるオンラインRFCアーカイブへの]

Healy                                                           [Page 4]

ヒーリー[4ページ]