rfc610.txt

RFC 相关的技术文档

given its own description. These descriptions are similar to those given
for stored data.  At a minimum this description must contain enough
information for the datacomputer to parse the incoming bit stream.  It
also may contain data validation information as well.  To store data at
the datacomputer, the stored data must also have a description.  The
user supplies the mapping between the descriptions of the stored and
transmitted data.
















Winter, Hill & Greiff                                          [Page 17]

RFC 610           Further Datalanguage Design Concepts     December 1973



 _____________________________________
|                                     |        / /
|  ______     ___________             |        \ \
| |      |---|           |            |        / /
| |      |   |   DATA    |            |        \ \
| |      |   |DESCRIPTION|   _______  |    DATALANGUAGE     ___________
| |      |   |___________|  |       |<-------------------->|           |
| |STORED|         |________| USER  | |        PATH        |APPLICATION|
| | DATA |__________________|REQUEST| |                    |  PROGRAM  |
| |      |                  |_______|<----!--------------->|___________|
| |      |               ___________  |   !   DATA PATH
| |      |              |           | |   !    / /
| |      |              |   PORT    |-----!    \ \
| |      |              |DESCRIPTION| |        / /
| |______|              |___________| |        \ \
|_____________________________________|        / /
                                             NETWORK
                               Figure 2-1
                A Model of Datacomputer/User Interaction



2.7.2 Application Features for Data Sharing

In using data stored at the datacomputer, users may supply a description
of the data which is customized to the application. This description is
mapped onto the description of the stored data. These descriptions may
be at different levels.  That is, one may merely rearrange the order of
certain items, while another could call for a total restructuring of the
stored representation. So that each user may be able to build upon the
descriptions of another, data entities should be given named types.
These type definitions are of course to be stored along with the data
they describe.  In addition, certain functions are so closely tied to
the data (in fact may be the data in the virtual description case -- see
section 3), that they must also reside in the datacomputer and their tie
with the data items should be maintained by the datacomputer.  For
example, one user can describe a data base as made up of structures
containing data of the types _latitude_ and _longitude_.  He could also
describe functions for comparing data of this type.  Other users, not
concerned with the structure of the _latitude_ component itself, but
interested in using this information simply to extract other fields of
interest can then use the commonly provided definitions and functions.
Furthermore, by adopting this strategy as many users as possible can be
made insensitive to changes in the file which are tangential to their
main interests.  For example, _latitudes_ could be changed from binary
representation to a character form and if use of that field were
restricted to its definitions and associated functions, existing



Winter, Hill & Greiff                                          [Page 18]

RFC 610           Further Datalanguage Design Concepts     December 1973


application systems would be unaffected.  Conversion functions could be
defined to eliminate the impact on currently operating programs.  The
ability of such definitional facilities means that groups of users can
develop common functions and descriptions for dealing with shared data
and that conventions for use of shared data can be enforced by the
datacomputer.  These facilities are discussed under _extensibility_ in
Section 3.


 ___________________________________________      _______________
|                             ____________  |    |  ___________  |
|                            |APPLICATION | |    | |APPLICATION| |
|                           _|    DATA    |_|____|_|  PROGRAM  | |
|                          | |DESCRIPTIONS| |    | |___________| |
|                          | |____________| |    |_______________|
|                          |       ^        |          HOST 1
|  ______                  |       |        |
| |      |                 |  _____|______  |
| |      |                 | |    DATA    | |
| |      |                 | | FUNCTIONS  | |
| |      |                 | |____________| |     _______________
| |      |   ___________   |  ____________  |    |  ___________  |
| |      |  |  STORED   |__| |            | |    | |APPLICATION| |
| |      |__|   DATA    |____|            |_|____|_|  PROGRAM  | |
| |STORED|  |DESCRIPTION|__  |            | |    | |___________| |
| | DATA |  |___________|  | |____________| |    |               |
| |      |        ^        |  ____________  |    |  ___________  |
| |      |        |        | |            | |    | |APPLICATION| |
| |      |   _____|_____   | |            |_|____|_|  PROGRAM  | |
| |      |  |   DATA    |  |_|            | |    | |___________| |
| |      |  | FUNCTIONS |    |____________| |    |_______________|
| |______|  |___________|                   |          HOST 2
|___________________________________________|
                DATACOMPUTER

                               Figure 2-2
            Multiple User Interaction with the Datacomputer



2.7.3 Communication Model

We intend that datalanguage, while at a high level conceptually, will be
at a low level syntactically.  Datalanguage provides a set of primitive
functions, and a set of commonly used higher level functions (see
section 4 on the datalanguage model).  In addition, users can define
their own functions so that they can communicate with the datacomputer
at a level as conceptually close to the application as possible.



Winter, Hill & Greiff                                          [Page 19]

RFC 610           Further Datalanguage Design Concepts     December 1973


There are two reasons for datalanguage being at a low level
syntactically.  First, it is undesirable to have programs composing
requests into an elaborate format only to be decomposed by the
datacomputer.  Second, by choosing a specific high level syntax, the
datacomputer would be imposing a set of conventions and terminology
which would not necessarily correspond to those of most users.


   DATACOMPUTER ENVIRONMENT     |      OUTSIDE ENVIRONMENT

                                |           _______
                                           |       |____
                                |        __|GENERAL|____
                                        |  |  DMS  |____
                                |       |  |_______|
 _________     ________     _________   |
|         |   | HIGHER |   |         |__|   _______     ________
|PRIMITIVE|___| LEVEL  |___|LOW-LEVEL|_____|COBOL  |   | COBOL  |
|LANGUAGE |   |LANGUAGE|   | SYNTAX  |__   |SERVER |___|PROGRAM |
|_________|   |________|   |_________|  |  |_______|   |________|
                                |       |   _______
                                        |__|ON LINE|
                                |          | QUERY |_______
                                           |_______|       |
                                |                       ___|____
                                                       |TERMINAL|
                                |                      | USERS  |
                                                       |________|
                                |
                                         APPLICATION  APPLICATIONS
                                |          SERVERS

                               Figure 2-3
                 Datacomputer/User Working Environment



2.8 Summary

In this section we have presented the major considerations which have
influenced the current datalanguage design effort.  The datacomputer has
much in common with most large-scale shared data management systems, but
also has a number of overriding concerns unique to the datacomputer
concept.  The most important of these are the existence of a separate
box containing both hardware and software, the control of an extremely
large storage device, and embedding in a computer network environment.
Data sharing in such an environment is a central concern of the design.
Both extensive data description facilities and high level communication



Winter, Hill & Greiff                                          [Page 20]

RFC 610           Further Datalanguage Design Concepts     December 1973


between user and datacomputer are necessary for data integrity and for
datacomputer optimization of user requests.  In addition, the expected
use of the datacomputer involves satisfying several conflicting
constraints for different modes of operation.  One way of satisfying
various user needs is to provide datalanguage features so that users may
develop their own application packages within datalanguage.













































Winter, Hill & Greiff                                          [Page 21]

RFC 610           Further Datalanguage Design Concepts     December 1973


3. Principal Language Concepts

This section discusses the principal facilities of datalanguage.
Specific details of the language are not presented, however, the
discussion includes the motivation behind the inclusion of the various
language features and also defines, in an informal way, the terms we
use.


3.1 Basic Data Items

Basic data are the atomic level of all data constructions; they cannot
be decomposed.  All higher level data structures are fundamentally
composed of basic data items.  Many types of basic data items will be
provided.  The type of an item determines what operations can be
performed on the item and the meaning of those operations.  Datalanguage
will provide those primitive types of data items which are commonly used
in computing systems to model the real world.

The following basic types of data will be available in datalanguage:
_fixed_point_numbers_, _floating_point_numbers_, _characters_,
_booleans_, and _bits_. These types of items are "understood" by the
datacomputer system to the extent that operations are based on the type
of an item.  Datalanguage will also include an _uninterpreted_ type of
item, for data which will only be moved (including transmitted) from one
place to another. This type of data will only be understood in the
trivial sense that the datacomputer can determine if two items of the
uninterpreted type are identical.  Standard operations on the basic
types of items will be available.  Operations will be included so that
the datacomputer user can describe a wide range of data management
functions.  They are not included with the intent of encouraging use of
the datacomputer for the solving of highly computational problems.


3.2 Data Aggregates

Data aggregates are compositions of basic data items and possibly other
data aggregates.  The types of data aggregates which are provided allow
for the construction of hierarchical relationships of data.  The
aggregates which will definitely be available are classified as
_structs_, _arrays_, _strings_, _lists_, and _directories_.

A struct is a static aggregate of data items (called _components_).  A
struct is static in the sense that the components of a struct cannot be
added or deleted from the struct, they are inextricably bound to the
struct.  Associated with each component of the struct is a name by which
that component may be referenced relative to the struct.  The struct
aggregate may be used to model what is often thought of as a record,



Winter, Hill & Greiff                                          [Page 22]

RFC 610           Further Datalanguage Design Concepts     December 1973


with each component being a field of that record.  A struct can also be
used to group components of a record which are more strongly related,