diff options
Diffstat (limited to 'doc/rfc/rfc515.txt')
| -rw-r--r-- | doc/rfc/rfc515.txt | 1739 |
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc515.txt b/doc/rfc/rfc515.txt new file mode 100644 index 0000000..3524553 --- /dev/null +++ b/doc/rfc/rfc515.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group R. Winter +Request for Comments: 515 Computer Corporation of America +NIC 16446 6 June 1973 + + + Specifications for Datalanguage, Version 0/9 + +Preface + + Datalanguage is the language processed by the Datacomputer, a data + utility system being developed for the Arpanet. The Datacomputer + performs data storage and data management functions for the benefit + of computers on the network. + + Version 0/9 is currently running at CCA. This version is extremely + primitive; however, it does offer an opportunity for experience with + the Datacomputer and with fundamental Datalanguage concepts. + + Subsequent versions will provide greater portions of the full + Datalanguage capability, which has been described earlier + (Datalanguage, Working Paper No. 3, Datacomputer Project, October, + 1971, NIC 8028). For example, one of the primary restrictions in + 0/9--elementary data items must be fixed-length ASCII strings--will + be eliminated in Version 0/10, which is currently being implemented. + + Based on the experience gained in the implementation of these early + versions, and based on the feedback from their use, a revised + specification of the full language will be issued. + +1. Introduction + + This document presents a precise and complete specification of + Datalanguage, Version 0/9. It is organized into 11 sections, of + which this introduction is the first. Section 2 discusses the + capabilities of Version 0/9 in general terms. Sections 3 and 4 are + concerned with data description and the directory. Sections 5 + through 8 cover the expression of data management operations. + Section 9 discusses the recognition of names. Section 10 covers + miscellaneous topics and Section 11 specifies the syntax in BNF. + + This specification is to be followed with a user manual, which will + present the language in tutorial form and treat components of the + Datacomputer-user interface other than the language. + + + + + + + + +Winter [Page 1] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + +2. Capabilities of Version 0/9 + + Version 0/9 of Datalanguage has capabilities for the storage of + files; for addition of data to existing files, and for the deletion + of files. Retrievals can output whole files as well as subsets of + files. Data can be selected from files by content, using expressions + formed from boolean and inequality operators. + + At the option of the file creator, an inversion is constructed and + maintained by the Datacomputer. The inversion increases the + efficiency of selective retrieval, at the cost of storage space and + file maintenance effort. Users other than the file creator need not + be aware of the existence of the inversion, or of which fields are + inverted file keys. The language is designed so that they state the + desired result of a retrieval, and the Datacomputer uses the + inversion as much as the request permits. + + Elementary data items are fixed-length ASCII strings. Files are a + restricted class of hierarchical structures. + + Many of the restrictions mentioned in this memo will be short-lived. + In particular, those statements followed with 3 asterisks (***) refer + to restrictions that will be considerably weakened or eliminated + entirely in the next version of the software. + +3. Data Description + + A container is a variable whose value is a data object of general + character and arbitrary size (In Version 0/9, size is restricted. + See section 3.4). Examples of containers which are implemented in + other systems are files, records, fields, groups, and entries. + + The container is distinct from the data in the container. For + example, space allocation is an operation on a container, while + changing the unit price field from 25 to 50 is an operation on data + in a container. + + A container may enclose other containers. When a container is not + enclosed by another container, it is said to be outermost. If + container A encloses container B, and no other container in A also + encloses B, then A immediately encloses B. + + A Datalanguage description is a statement of the properties of a + container. + + All containers have the attributes ident and type. Ident is a + character string by which users refer to the container. Type + determines the form of the container's value; the value can be + + + +Winter [Page 2] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + elementary, or it can consist of other containers. There are 3 + types: LIST, STRUCT, and STRING(***). A LIST contains a group of + containers having the same description. A STRUCT contains a group of + containers, each of which has its own description. A STRING is a + sequence of ASCII characters. While a STRING is not really an + elementary item, it is handled as one in Version 0/9. + + Certain containers can have other attributes. An outermost container + has a function. The function attribute specifies whether the + container is to be used for storage or for transmission. + + Size is some meaningful dimension of the container, which is type- + dependent. It is used for space allocation and data stream parsing. + + An aggregate container (i.e., one that contains other containers) has + as an attribute the description or descriptions of its components. + Thus if S is a STRUCT containing A, B, and C, then the descriptions + of A, B, and C are attributes of S. + + A STRING defined in certain contexts can have an inversion attribute. + This is an access property that is not really local to the STRING, + but is associated with it for convenience. + +3.1 Ident + + The ident of a container is composed of alphanumeric characters, + the first of which is alphabetic. It may not consist of more than + 100 characters. + + The elements of a STRUCT must have idents unique in the STRUCT. + +3.2 Function + + The function of a container is either FILE, PORT, or TEMPORARY + PORT. When the function is FILE, then the container is used for + storage of data at the Datacomputer. When the function is PORT, + then the container is used for transmission of data into or out of + the Datacomputer. When the function is TEMPORARY PORT (which may + be abbreviated TEMP PORT), the container behaves like a PORT; + however, its description is not retained in the Datacomputer + beyond the session in which it is created. + + + + + + + + + + +Winter [Page 3] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + +3.3 Type + + Type is one of: LIST, STRUCT, or STRING. These are defined on the + preceding page. + + In an occurrence of a STRUCT, the elements appear in the order in + which their descriptions appear in the STRUCT description. All + elements are present in each occurrence of the STRUCT. + + An element of a STRUCT or LIST can be a container of any datatype. + However, the outermost container must be a LIST(***). + +3.4 Size + + The size of a STRING is the number of characters in it. The size + of a STRUCT is not defined (***). The meaning of the size of a + LIST depends upon other properties of the LIST (***). + + Ordinarily, the size of a LIST is the number of LIST-members. An + exception is the case of the outermost-LIST. In an outermost-LIST + with a function of FILE, the size is the number of LIST-members + for which space should be allocated. When no size is present in + this case, the system computes a default. In an outermost-LIST + with a function of PORT, the size is ignored (***). + + Only outermost containers may be larger than a TENEX page (2560 + ASCII characters)(***). + +3.5 Inversion + + An inversion is an auxiliary data structure used to facilitate + retrieval by content. + + Its basic application is the fast retrieval of sets of outermost- + LIST-members (this can be extended to other container sets, and + will be after release 1). Consider a list of weather + observations, stored as a file on the Datacomputer. If quick + retrieval of observations by COUNTRY is desired, then this is + indicated in the description of the COUNTRY container. According + to common usage in information retrieval, this makes COUNTRY a key + in the retrieval of observations. + + Note that the inversion option only affects the efficiency of + retrieval by COUNTRY, not the ability to retrieve by COUNTRY. + + + + + + + +Winter [Page 4] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + There are restrictions on use of the inversion option. First, it + can be applied only to STRINGs. Second a STRING having the + inversion option must occur only once in each + outermost-LIST-member. Third, it is ignored when applied to + STRINGs in PORT descriptions. + + Eventually there will be several types of inversion option; in + Version 0/9 there is only the 'D' option (for distinct). + +3.6 Syntax + + The description is simply an enumeration of properties; these + properties are specified in the order: + + <ident> <function> <type> <size> <other> + + Properties which do not apply are omitted. An example: + + F FILE LIST (25) A STR (10) + + Here 'F' is the <ident>, 'FILE' is the <function>, 'LIST' is the + <type>, '(25)' is the size, and 'A STR (10)' is the <other> of one + description. Of course, 'A STR (10)' is itself another + description: the description for members of the LIST named F. + + An example of a complete description for a file of weather + observations keyed on location: + + WEATHER FILE LIST + OBSERVATION STRUCT + LOCATION STRUCT + CITY STR (10), I=D + COUNTRY STR (10), I=D + END + TIME STRUCT + YEAR STR (2) + DAY STR (3) + HOUR STR (2) + END + DATE STRUCT + TEMPERATURE STR (3) + RAINFALL STR (3) + HUMIDITY STR (2) + END + END + The ENDs are needed to delimit the list of elements of a STRUCT. + `, I=D' indicates that the string is to be an inversion key for + the retrieval of outermost-LIST-members. + + + +Winter [Page 5] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + +4. Directory + + The directory is a system file in which the names and descriptions of + all user-defined containers are kept. + + The directory is structured as a tree. Each node has an ident, which + need not be unique. There is a single path from the root of the tree + to any node. The idents of the nodes along this path are + concatenated, separated by periods, to form a pathname, which + unambiguously identifies the node (e.g., A.B.C could be a pathname + for node with an ident of C). + + In a later version of the software, the directory will be generalized + to provide for links between nodes, so that it will not properly be a + tree. For now, however, the tree model is convenient and adequate. + + A node may represent a container, or it may simply hold a place in + the space of pathnames. When it represents a container, it cannot + (currently) have subordinate nodes. + + Eventually, it is planned to model the directory as a structure of + containers, with its description distributed throughout the + structure. Most operations defined on the directory will be defined + on user data, and vice versa. Access privileges and privacy locks + will be part of the data description and will likewise be applicable + both to directory nodes and data structures below the node level. + +4.1 CREATE + + A CREATE-request either; (a) adds a node to the directory, + optionally associating the description of either a PORT or a FILE + with the node, or (b) creates a temporary container which is not + entered in the directory, but has a description and can be + referenced in requests. If the description defines a file, CREATE + causes space to be allocated for the file. + + To create a node with a description: + CREATE <pathname> <description> ; + To create a node with no description: + CREATE <pathname> ; + Note that the description determines whether or not the container + is temporary (see section 3.2 for details). + + + + + + + + + +Winter [Page 6] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + A CREATE-request adds a single node to the directory. Thus to add + CCA.RAW.F to an empty directory, three requests are needed: + CREATE CCA ; + CREATE CCA.RAW ; + CREATE CCA.RAW.F ; + Notice that the last ident of the pathname doubles as the first + ident of the description: + CREATE CCA.RAW.G FILE LIST A STR (5) ; + + That is, G is both the ident of a node and the ident of an + outermost container of type LIST. + +4.2 DELETE + + A DELETE-request deletes a tree of nodes and any associated + descriptions or data. The syntax is: + DELETE <pathname> ; + The named node and any subordinates are deleted. + + Note that to delete data while retaining the directory entry and + description, DELETE should not be used (see section 6.3 for the + proper method). + +4.3 LIST + + The LIST-request is used to display system data of interest to a + user. It causes the data specified to be transmitted through the + Datalanguage output port. + + Several arguments of LIST apply to the directory. LIST %ALL + transmits all pathnames in the directory. LIST %ALL.%SOURCE + transmits all descriptions in the directory. Instead of %ALL, a + pathname can be used: + LIST <pn>.%ALL + Lists pathnames subordinate to <pn>. + LIST <pn>.%SOURCE + lists descriptions subordinate to the node represented by <pn>. + + For details about the LIST-request, see section 10.1. + +5. Opening and closing containers + + Containers must be open before they can be operated on. + + A container is open when it is first created. It remains open until + closed explicitly by a CLOSE-request or implicitly by a DELETE- + request or by session end. + + + + +Winter [Page 7] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + A closed container is opened by an OPEN-request. A temporary + container is always open; a CLOSE-request deletes it. + +5.1 Modes + + An open container has a mode, which is one of: READ, WRITE, or + APPEND. The mode determines the meaning and/or legitimacy of + certain operations on the container. + + The mode is established by the operation which opens the + container. It can be changed at any time by a MODE-request. A + CREATE leaves the container in WRITE mode. An OPEN either + specifies the mode explicitly or implicitly sets the mode to READ. + +5.2 Syntax + + To open a container: + OPEN <pathname> <mode> ; + or: + OPEN <pathname> ; + where <mode> is defaulted to READ. + + To close a container: + CLOSE <ident> ; + where <ident> is the name of an outermost container. + + Two containers with the same outermost <ident> can not be + opened at the same time (***). + + To change the mode of an open container: + MODE <ident> <newmode> ; + +5.3 LIST + + LIST %OPEN transmits name, mode and connection status of each open + outermost container through the Datalanguage output port. (The + Datalanguage output port is the destination to which all + Datacomputer diagnostics and replies are sent. It is established + when the user initially connects to the Datacomputer.) For + details of the LIST-request, see section 10.1. + +6. Assignment + + Assignment transfers data from one container to another. + + The equal sign ('=') is the symbol for assignment. The value of the + operand on the right of the equal sign is transferred to the operand + on the left. (Eventually, both operands will be weakly-restricted + + + +Winter [Page 8] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + Datalanguage expressions, which may evaluate to sets as well as to + single containers. Now, the left must be a container name, the right + may be a container name or a constant.) + + Assignment is defined for all types of containers. When the + containers are aggregates, their elements are paired and data is + transferred between paired elements. Elements of the target + container that do not pair with some source element are handled with + a default operation (currently they are filled with blanks). + + The operands of an assignment must have descriptions that match. The + idea of matching is that the descriptions must be similar enough so + that it is obvious how to map one into the other. + +6.1 Conditions for legitimate assignment + + Assignment must reference objects, not sets. An object is: + (a) an outermost container, or + (b) a constant, or + (c) in the body of a FOR-loop, either + (c1) a member of a set defined by a FOR-OPERAND, or + (c2) a container which occurs once in such a member + + In the case of a reference of type (c1), the object referenced is + taken to be the current member. In the case of (c2), the object + referenced is that which occurs in the current member. This is + explained further in section 7. + + The left operand of an assignment is subject to further + restriction. If it is an outermost container, it must be open in + either WRITE- or APPEND-mode. If it is not an outermost + container, then the reference is of type (c), which means that + some FOR-operand has established a context in which the assign- + operand is an object. The FOR-operand which establishes this + context must be the output-operand of the FOR. + + When the assign-operand is an outermost container, it must be + open. Such an operand must be referenced by its simple container + ident(***), not its directory pathname. + + In the body of a loop nested in one or more other loops, + assignments are further restricted, due to a 0/9 implementation + problem. See section 7.2 for details. + + + + + + + + +Winter [Page 9] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + Finally, the descriptions of the operands must match. If one is a + constant, then the other must be a STRING(***). If both are + containers, then in the expression: + A = B; + the descriptions of containers A and B match if: + 1. A and B have the same type + 2. If A and B are LISTs, then they have equal numbers of + LIST-members, or else A is an outermost-LIST. + 3. If A and B are aggregates, then at least one container + immediately enclosed in A matches, and has the same ident as, one + container immediately enclosed in B. + +6.2 Result of assignment + + If the operands are STRINGs, then the value of B, left-justified, + replaces the value of A. If B is longer than A, the value is + truncated. If B is shorter than A, then A is filled on the right + with blanks as necessary. + + If the operands are STRUCTs, then assignment is defined in terms + of the STRUCT members. If a member of A, mA, matches and has the + same name as a member of B, mB, then mB is assigned to mA. If no + such mB exists, then mA is filled with blanks. + + If the operands are LISTs, the result depends on several factors. + First, notice that the descriptions of the LIST-members must + match; otherwise the assignment would not be legitimate by the + matching rules of 6.1. + + If A is an outermost-LIST, then it can be in either of two modes: + WRITE or APPEND. If A is in WRITE-mode, its previous contents are + first discarded; it is then handled as though it were in APPEND- + mode. + + If A is not an outermost-LIST, then it is always effectively in + WRITE-mode. + + After taking the mode of A into account, as described above, the + procedure is: + for each member of LIST B + (a) add a new member to the end of A + (b) assign the current number of B to the new member of A + + + + + + + + + +Winter [Page 10] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + +6.3 Deletion of Data Through Assignment + + If A is an outermost container in WRITE-mode, and B is a container + with description that matches A, and if B contains no data, then + A=B has the effect of deleting all data from A. Note that if A is + in APPEND-mode in these circumstances, then A=B is a no-operation + (i.e., has no effect). + +7. FOR + + FOR <output set spec>, <input set spec> <body> END ; + + The output set is optional: that is, FOR need not produce output. + When the output set is omitted, the syntax is: + + FOR <input set spec> <body> END ; + + The operations specified in the body are performed once for each + member of the input set. References in the body to the input set + member are treated as references to the current input set member. + When an output set is present, a new member is created and added to + the output set for each iteration (i.e., for each input set member). + References to the output set member, similarly, are treated as + references to the current output set member. + + The output set spec must be the name of a LIST member. Each + iteration of the FOR will create one such member, and add it to its + LIST (hereafter called the output LIST). The body terminates the + value that the new member receives. Any STRING in the new member + which is not given a value by the body receives he default value of + all blanks. + + The input set spec must be an expression evaluating to a set of + LIST-members (see section 7.1 for details of input set + specification). Each iteration for the FOR will input one such + member; the FOR will terminate when each member of the set has been + processed. The LIST from which the input set members are drawn is + called the input LIST. + + FOR is effectively a means of accomplishing variants of assignment + between a pair of LISTS. FOR is less concise than assignment, but + offers more flexibility. Its advantages are: + (a) not all the input LIST-members need be transferred to the + output LIST. A subset can be selected by content. + (b) the user has explicit control over the assignment of values to + output LIST-members. + + + + + +Winter [Page 11] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + This is most easily understood by an example: + P PORT LIST F FILE LIST + R STRUCT R STRUCT + B STR A STRUCT + C STR A1 STR + END A2 STR + B STR + C STR + END + + (1) P = F ; + (2) FOR P.R, F.R + P.R = F.R ; + END ; + (3) FOR P.R, F.R WITH A1 EQ 'XY' OR A2 GE 'AB' + B = C ; + C = A2 ; + END + + Here, (1) and (2) are entirely equivalent requests. However, (3) is + quite different and is not expressible as assignment. It selects a + subset of F.Rs. The values it gives to the P.Rs could not result + from application of the matching rules to F and P. + + Because FOR is effectively assignment between a pair of LISTs, the + LISTs referenced by a legitimate FOR-operation are largely subject to + the same restrictions as LISTs referenced in an assignment. One + exception is that the descriptions of the LIST-members need not + match. + + These restrictions are: + (a) both LISTs must be objects in the context in which the FOR + appears. + (b) both LISTs must be open or contained in open outermost + containers. + (c) if the output LIST is an outermost container, it must be in + WRITE- or APPEND-mode. + (d) If the output LIST is not outermost, the LIST which most + immediately encloses it must be the output LIST of an enclosing + FOR. + + The mode of the output LIST of the FOR affects the result much as it + would in an assignment: that is, a FOR outputting to a LIST in + WRITE-mode overwrites previous contents, while a FOR outputting to a + LIST in APPEND-mode adds to previous contents. + + + + + + +Winter [Page 12] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + CAUTION TO THE READER: For convenience, these specifications use + phrases such as 'LISTs referenced by a FOR'. Recall that such a + phrase is not literally correct, in the sense that the operands of a + FOR are always LIST members, not LISTs. + +7.1 Details of input set specification + + The input set is specified by a Datalanguage expression that + evaluates to a set of LIST-members. Such an expression can be + simply the set of all members of a LIST, or it can be a subset of + the members of a LIST, specified by content. For example, with + the description: + + F FILE LIST + R STRUCT + A STR (1) + B STR (2) + END + + the expression: + F.R + references all R's on the LIST F. However: + F.R WITH A EQ '5' + references only those R's containing an A having the value '5'. + The expressions permitted as input set specifications are of the + form: + <list-member-name> WITH <boolexp> + The <boolexp> is constructed of comparison expressions joined by + the Boolean operators AND and OR. Any expression can be negated + with NOT. + + Comparison operators have the highest precedence. Next highest is + AND, then OR, then NOT. + + The comparison expressions are restricted to the form: + <container name> <comop> <constant> + where: + (a) <constant> is a string constant enclosed in single quotes + (see section 10.2 for a discussion of constants) + (b) <comop> is one of six operators: + EQ equal + NE not equal + LT less than + GT greater than + LE less than or equal to + GE greater than or equal to + (c) <container name> is the name of a STRING that appears once + in each LIST-member. + + + +Winter [Page 13] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + The constant is truncated or padded with blanks on the right to + make it equal in size to the container to which it is being + compared. Notice that padding on the right is not always + desirable (users will have control over the padding in a future + release). In particular, care must be exercised when using + numbers in Version 0/9. (A number represented as a STRING should + actually be described as a number; eventually it will be possible + to do this). + +7.2 FOR-body + + Two operations are legitimate in a FOR-body: FOR and assignment. + + These are subject to the restrictions discussed in Section 6.1 and + in the introduction to Section 7. The restrictions are related to + three requirements: (1) that the names be recognizable (see + Section 9 for details), (2) that a request be consistent regarding + direction of data transfer between containers, both within itself + and with the MODE of outermost containers, and (3) that transfers + occur between objects, not sets of objects. The first two + requirements are permanent, but will become weaker in later + versions of the language. The last requirement is temporary and + will be present only in early versions. + + Due to an implementation problem associated with Version 0/9, + there is a somewhat bizarre restriction applied to references made + in the body of a loop nested in another loop. This restriction is + not expected to pose any practical problems for users, and is not + part of the language design, but is discussed here for + completeness. + + The restriction is most easily understood by example: + + given the description + F LIST + R STRUCT + A STR (3) + BL LIST (3) + B STR (3) + C STR (3) + END + and the request fragment: + FOR ...,R + FOR ...,B + ... = A ; + ... = C ; + END + END + + + +Winter [Page 14] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + observe: + (a) The outer loop processes the set of R's in F. + (b) For each R in F, the inner loop processes the set of B's in + the BL contained in that R. + (c) In the body of the inner loop, there are references to A and + C, which do not occur in B, but do occur in R. That is, the + objects referenced in the inner loop body are defined by the + outer loop, not the inner loop. In general, this is fine; + in the case of C, however, we have a problem. + (d) C occurs beyond the end of BL. + + The 0/9 compiler is capable of neither (1) looking ahead enough to + locate C before it compiles code for the loop, nor (2) while + generating code to loop on the B's in BL, generating a separate + body of code that skips to the end of BL to locate C. Thus it can + handle A, which has been located before it begins loop generation, + but it cannot handle C, which requires a little foresight. + + The request fragment shown would not cause problems if the + description were changed to: + + F LIST + R STRUCT + A STR (3) + C STR (3) + BL LIST (3) + B STR (3) + END + + Then both A and C would have been found before code for the inner + loop was generated. + +8. Data Transmission + + Data is transferred from container to container by execution of + assignment and FOR operations. The outermost containers involved in + transfers can be files or ports. If both are files, then the + transfer is internal to the Datacomputer. If either is a port, then + an address in the external world is needed to accomplish the data + transmission. + + + + + + + + + + + +Winter [Page 15] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + Such an address is supplied through a CONNECT-request, which + associates a container (having a function of PORT) with an external + address: + CONNECT <ident> TO <address> ; + Here <address> is either a specifications of host and socket number, + or a TENEX file designator (for CCA's TENEX) enclosed in single + quotes. The host and socket form is: + <socket> AT <host> + where <socket> is a decimal number, and <host> is either a decimal + number or a standard host name (since standard host names don't exist + right now, it has to be the TENEX 'standard' name for the host. + Contact the author for the latest list.) If <host> is omitted, it is + taken to be the host from which the Datalanguage is being + transmitted. + + The address associated with a port can be changed by issuing another + CONNECT-request. + + A DISCONNECT-request simply breaks an existing port/address + association without establishing a new one. (A CLOSE-request that + references an open port executes a DISCONNECT.) The syntax of + DISCONNECT is: + DISCONNECT <ident> ; + + A port is disconnected when: (a) no successful CONNECT-request has + ever been issued for it, or (b) a DISCONNECT for the port has been + executed since the last successful CONNECT. + + When a disconnected port is referenced in an assignment, it is + connected by default either to: + (a) the connection used for the transmission of Datalanguage to the + Datacomputer, or + (b) the connection used for the transmission of Datacomputer + diagnostics to the user + The choice between (a) and (b), of course, depends on whether the + reference is for input or output. These connections are established + by the network user's ICP to the Datacomputer at the beginning of the + session. + + Note that CONNECT and DISCONNECT do not open files or network + connections. They simply make address associations within the + Datacomputer. The files and connections are opened before each + request and closed after each request. + + + + + + + + +Winter [Page 16] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + +9. Names in Datalanguage + + A name is recognized when it has been associated with a particular + data container or set of containers. + + Datalanguage has mechanisms for the recognition of names in contexts. + That is, the meaning of the name is related to where it appears. + + This makes it possible to attach natural meanings to partially + qualified names. + + For example: + + WEATHER FILE LIST + STATION STRUCT + CITY STR (15) + STATE STR (15) + DATA LIST (24) + OBSERVATION STRUCT + HOUR STR (2) + TEMPERATURE STR (3) + HUMIDITY STR (2) + PRESSURE STR (4) + END + END + + RESULTS PORT LIST + RESULT STRUCT + CITY STR (15) + HOUR STR (2) + TEMPERATURE STR (3) + END + + FOR STATION WITH STATE EQ 'CALIFORNIA' + FOR RESULT, OBSERVATION WITH HOUR GT '12' + AND HUMIDITY LT '75' + CITY = CITY ; + HOUR = HOUR ; + TEMPERATURE = TEMPERATURE ; + END ; + END ; + + in the assignment 'CITY = CITY', the first CITY is understood to be + RESULT.CITY and the second is understood to be STATION.CITY. + + + + + + + +Winter [Page 17] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + +9.1 Informal Presentation of Recognition Rules + + 'Ident' is used in the sense of section 3. For example, in the + description: + F FILE LIST R STRUCT A STR (1) B STR (1) END + F, R, A and B are idents. + + A context is a tree whose nodes are idents. In such a tree, the + terminal nodes are idents of STRINGs. The ident of a LIST is + superior to the ident of the LIST-member. The ident of a STRUCT + is superior to the idents of the STRUCT elements. The context + whose top node is F is said to be the context of F. + + +-----+ + ! F ! + +-----+ + ! + ! + +-----+ + ! R ! + +-----+ + ! + ! + +----------+----------+ + ! ! + ! ! + +-----+ +-----+ + ! A ! ! B ! + +-----+ +-----+ + + + + Figure 9.1-1 The context of F + + A pathname is a sequence of idents, naming nodes along a path from + one node to another. A full pathname in the context starts at the + topmost node. Thus F.R.B is a full pathname in the context of F. + A partial pathname starts at a node other than the topmost node + (e.g. R.B, B). + + In Datalanguage, pathnames omitting intermediate nodes, such as + F.B (which omits 'R'), are not permitted. Thus partial pathnames + are partial only in that additional names are implied on the left. + + + + + + + + +Winter [Page 18] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + Three attempts at recognition of a pathname, PN, in a context, CX, + are made: + + (a) recognition of PN as a full pathname in CX + (b) recognition of PN as a partial pathname in which only the + topmost node of CX is omitted + (c) recognition of PN as an arbitrary partial pathname occurring + only once in CX. + + The attempts are made in the above order, and the recognition + process halts with the first successful attempt. + + As an example, consider the description: + + F FILE LIST + R STRUCT + A STR + B STR + S STRUCT + R STR + + which defines the context in Figure 9.1-2. + + + +-----+ + ! F ! + +-----+ + ! + ! + +-----+ + ! R ! + +-----+ + ! + ! + +----------------+----------------+ + ! ! ! + ! ! ! + +-----+ +-----+ +-----+ + ! A ! ! B ! ! S ! + +-----+ +-----+ +-----+ + ! + ! + +-----+ + ! R ! + +-----+ + + Figure 9.1-2 Example Context + + + + +Winter [Page 19] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + In this context, F.R.A is a full pathname. Thus, F.R.A is + recognized in attempt (a). R is a partial pathname in which only + the topmost node is omitted. Thus R is recognized in attempt (b). + Note carefully that R is recognized as a reference to F.R, not to + F.R.S.R. Finally, B is an arbitrary partial pathname occurring + only once in the context. Thus B is recognized in attempt (c). + + Two stacks of contexts are maintained: one for names used in an + input sense, and one for names used in an output sense. When a + name is to be recognized, it is first decided whether the + reference is an input reference or an output reference. An input + reference is (a) the right hand operand of an assign, or (b) a + name in the input set spec of a FOR. An output reference is (a) + the left operand of an assign, or (b) the output operand of a FOR. + The first context on the appropriate context stack is then + searched, according to the procedure outlined on the previous + page. If the name is neither recognized nor ambiguous in that + context, search continues in the next context on the stack. If + the name can be recognized in none of the contexts on the + appropriate stack, it is unrecognizable. + + When a stack is empty, the recognition procedure is different. + The search is carried on in a special context: The context of + %OPEN. Its top node, %OPEN, is a built in system ident. + Subordinate to %OPEN is a context for each open directory node. + Each such context represents all the idents defined in the + directory nodes having data descriptions: + F FILE LIST R STRUCT A STR (1) B STR (1) + and: + P PORT LIST R STRUCT A STR (1) B STR (1) + then the context of %OPEN would be as in Figure 9.1-3. + + + + + + + + + + + + + + + + + + + + +Winter [Page 20] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + +-------+ + ! %OPEN ! + +-------+ + ! + ! + +-----------+-----------+ + ! ! + ! ! + +-----+ +-----+ + ! A ! ! S ! + +-----+ +-----+ + ! ! + ! ! + +-----+ +-----+ + ! R ! ! R ! + +-----+ +-----+ + ! ! + ! ! + +-----+-----+ +-----+-----+ + ! ! ! ! + ! ! ! ! + +-----+ +-----+ +-----+ +-----+ + ! A ! ! B ! ! A ! ! B ! + +-----+ +-----+ +-----+ +-----+ + + + Figure 9.1-3 The Context of %OPEN + + When a directory node is closed, the corresponding context is + removed from the context of %OPEN. When a node is opened, the + associated context is added as the rightmost context subordinate + to %OPEN. + +9.2 Context Stack Maintenance + + The context stacks are always empty between requests. The FOR- + operator adds entries to the stacks. FOR A adds the context of A + to the input context stack. FOR A, B ... adds the context of A to + the output stack and the context of B to the input stack. + + When adding to an empty stack, FOR adds two contexts instead of + one. The second addition to the stack is the context of the + looparg; the first addition is the context of the outermost + container which encloses the looparg. + + + + + + + +Winter [Page 21] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + For example, given a context of %OPEN as in Figure 9.1-3, and + empty context stacks, the fragment 'FOR F.R ...' adds two + contexts: (1) the context of F, and (2) the context of F.R. + + Contexts are removed from the stacks by the END matching the FOR + which added them. + +10. Miscellaneous Topics + +10.1 The LIST-request + + The LIST-request provides a means for the user to inspect system + data of interest to him. The user can determine the contents of + the directory, the source or parsed form of any data description + in the system, and the mode and connection status of any open file + or port. + + The LIST operator has a single operand, which can have any of + several forms. The action of the operator is to output a list of + values on the Datalanguage output port. + + To output a list of pathnames, the operand used is '%ALL'. When + '%ALL' appears alone, all pathnames in the directory are listed. + When '%ALL' appears after the last ident in a directory pathname, + the full pathnames of all nodes subordinate to the named node are + listed. + + To output one or more source descriptions, the operand '.%SOURCE' + is used. '.%SOURCE' is preceded with one of (a) '%ALL', (b) + '%OPEN', or (c) the ident of an open outermost container. The + output is either (a) all descriptions, (b) all open descriptions, + or (c) a particular open description. + + To output a parsed description, the operand '.%DESC' is used + ('%DESCRIPTION' is also accepted). This operand is preceded + either with (a) '%OPEN', or (b) the ident of an open outermost + container. + + + + + + + + + + + + + + +Winter [Page 22] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + Examples: + + Let P be the ident of an open PORT. Let A.B.C be a + directory pathname. + LIST %ALL + LIST A.B.C.%ALL + LIST %OPEN + LIST %ALL.%SOURCE + LIST %OPEN.%SOURCE + LIST P.%SOURCE + LIST %OPEN.%DESC + LIST P.%DESC + + Note that 'LIST A.B.C.%SOURCE' is not legal - '.%SOURCE' + must be preceded with the ident of an open container, not a + pathname. A similar restriction applies to '.%DESC'. + +10.2 Constants in Datalanguage + + A constant of type STRING can be included in a Datalanguage + request by enclosing it in single quotes: + 'ABC' + A single quote is included in a constant by preceding it with a + double quote: + 'FATHER"'S' + Likewise, a double quote is included by preceding it with a double + quote: + 'JOHN SAID ""HELLO""' + + Such constants can be used on the right of comparison operators + and of assignment operators which reference strings. + + Eventually, Datalanguage will contain facilities for the inclusion + of constants of all datatypes; such constants are simply a special + case of the Datalanguage expression and will be permitted wherever + such expressions are permitted. + +10.3 Character Set + + Internally, Version 0/9 of the Datacomputer software operates in + 7-bit ASCII characters. Its output to the ARPANET is converted to + 8-bit ASCII. On input from the ARPANET, it expects 8-bit + characters, which it converts to 7-bit characters. + + + + + + + + +Winter [Page 23] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + To convert from 7- to 8-bit characters, a '0' bit is prefixed. To + convert from 8- to 7-bit characters, the high-order bit is + checked. If the high-order bit is a '0', the bit is discarded and + the character is accepted as a 7-bit character. If the high-order + bit is a '1', then the character is discarded. + + (In the following discussion, as elsewhere in this memo, all + references to numerical character codes are in decimal). + + The remainder of this section discusses treatment of codes 0 + through 127, when they appear in Datalanguage requests. + + In general, printing characters are acceptable in requests, while + control characters are not. There are some exceptions, which are + detailed below. The printing characters are codes 32-126. The + control characters are codes 0-31 and 127. + + Certain control characters are accepted: + + Tab(9) is accepted freely in requests. It functions as a + separator (explained below). + + EOL(31), meaning end-of-line, is accepted in requests, + functioning both as a separator and an activator (a). EOL has + a special meaning in data, and should not be introduced into + STRING constants(***). + + Control-L(12) is an activator and a high-level request + delimiter. It terminates the test of any request being + processed when it is encounter in the input stream. It is + useful in Datacomputer-user program synchronization. + + Control-Z(26) means end-of-session when encountered in + Datalanguage. It has the properties of control-L, and in + addition, causes the Datacomputer to execute an end-of-session + procedure, which results in closing the Datalanguage + connections, closing any open files or ports, etc. The effect + is equivalent to a [LOGOUT(which] does not exist yet). + + The two-character sequence <carriage return(13), line feed(10)> + is equivalent to EOL (and is translated to EOL on input from + the network). The reverse sequence, as well as either + character alone, is treated simply as other control characters + (ignored). + + All other control characters are ignored. + + + + + +Winter [Page 24] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + The printing characters are further divided into four groups: + special characters, uppercase letters, lower case letters, and + digits (the membership of these groups is defined in section 11). + + Corresponding upper and lower case letters are equivalent in + requests, except with quoted strings. + + Certain special characters have a lexical function, which is + either break or separator. A break character terminates the + current lexical item and returned itself as the next item. A + separator character terminates the current item but does not begin + a new item (i.e., its only function is to separate items). + Multiple separators are equivalent to a single separator. A + separator can always be inserted before or after a break + character, without altering the meaning of the request. + + The separators are tab(9), space(32), and end-of-line(31). + + The break characters are left parenthesis(40), right + parenthesis(41), equals(61), semicolon(59), period(46), comma(44), + quote(39), and slash(47). + + (a) An activator character causes the Datacomputer to process + whatever has been received since the previous activator or + the beginning of the request. The meaning of a request is + independent of the presence/absence of activators. However, + a request will not be executed until an activator beyond the + end of the request is received. + + While Version 0/9 defines (carriage return, linefeed) in terms of + EOL, network users should not think in terms of sending EOL's to + the Datacomputer over the network. EOL is not part of the network + ASCII character set, and has no definite permanent place in + Datacomputer implementation plans. + +10.4 Comments + + Comments can be included in Datalanguage requests. A comment is + begun with the two-character sequence '/*', and ended with the + two-character sequence '*/'. Since slash is a break character, a + comment does cause a lexical break; its overall effect is that of + a separator. + + + + + + + + + +Winter [Page 25] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + +10.5 Reserved Identifiers + + Certain identifiers are reserved in Datalanguage, and should not + be used to name containers or directory nodes. These are: + + AND + APPEND + AT + CLOSE + CONNECT + CREATE + DELETE + DISCONNECT + END + EQ + FILE + FOR + GE + GT + LE + LIST + LT + NODE + NE + NOT + OPEN + OR + PORT + READ + STR + STRUCT + TO + WITH + WRITE + + More reserved identifiers will be added in Version 0/10. + + + + + + + + + + + + + + + +Winter [Page 26] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + +11. Datalanguage Syntax Expressed in BNF + +11.1 Requests + + 11.1.01 <request> ::= ; + 11.1.02 <request> ::= <create> + 11.1.03 <request> ::= OPEN <pn> ; + 11.1.04 <request> ::= OPEN <pn> <mode> ; + 11.1.05 <request> ::= CLOSE <ident> ; + 11.1.06 <request> ::= CONNECT <ident> TO <address> ; + 11.1.07 <request> ::= DISCONNECT <ident> ; + 11.1.08 <request> ::= MODE <ident> <mode> ; + 11.1.09 <request> ::= DELETE <pn> ; + 11.1.10 <request> ::= LIST <listarg> ; + 11.1.11 <request> ::= <sr-request> ; + +11.2 Data Description and Creation + + 11.2.01 <create> ::= CREATE <pn> + 11.2.02 <create> ::= CREATE <pn> <ftn> LIST <desc> + 11.2.03 <create> ::= CREATE <pn> <ftn> LIST <size> <desc> + + 11.2.04 <desc> ::= <ident> <attributes> + + 11.2.05 <attributes> ::= LIST <size> <desc> + 11.2.06 <attributes> ::= STRUCT <descs> END + 11.2.07 <attributes> ::= STR <size> + 11.2.08 <attributes> ::= STR <size> ,I=D + + 11.2.09 <descs> ::= <desc> + 11.2.10 <descs> ::= <descs> <desc> + + 11.2.11 <ftn> ::= PORT + 11.2.12 <ftn> ::= FILE + 11.2.13 <ftn> ::= TEMP PORT + 11.2.14 <ftn> ::= TEMPORARY PORT + + 11.2.15 <size> ::= ( <integer constant> ) + + + + + + + + + + + + + +Winter [Page 27] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + +11.3 Data Storage and Retrieval + + 11.3.01 <sr-request> ::= <assign> + 11.3.01 <sr-request> ::= <loop> + + 11.3.03 <assign> ::= <pn> = <object> + + 11.3.04 <loop> ::= FOR <looparg> <loopbody> END + + 11.3.05 <looparg> ::= <exp> + 11.3.06 <looparg> ::= <pn> , <exp> + + 11.3.07 <loopbody> ::= <sr-request> + 11.3.08 <loopbody> ::= <loopbody1> <sr-request> + 11.3.09 <loopbody> ::= <loopbody1> + + 11.3.10 <loopbody1> ::= <sr-request> ; + 11.3.11 <loopbody1> ::= <loopbody1> <sr-request> ; + +11.4 Expressions + + 11.4.01 <exp> ::= <pn> + 11.4.02 <exp> ::= <pn> WITH <boolexp> + + 11.4.03 <boolexp> ::= <pn> <comop> <string constant> + 11.4.04 <boolexp> ::= ( <boolexp> ) + 11.4.05 <boolexp> ::= NOT <boolexp> + 11.4.06 <boolexp> ::= <boolexp> AND <boolexp> + 11.4.07 <boolexp> ::= <boolexp> OR <boolexp> + + 11.4.08 <comop> ::= EQ + 11.4.09 <comop> ::= NE + 11.4.10 <comop> ::= GT + 11.4.11 <comop> ::= LT + 11.4.12 <comop> ::= GE + 11.4.13 <comop> ::= LE + + + + + + + + + + + + + + + +Winter [Page 28] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + +11.5 Miscellaneous + + 11.5.01 <address> ::= <quote> <TENEX file designator> + <quote> + 11.5.02 <address> ::= <socket> AT <host> + 11.5.03 <address> ::= <socket> + + 11.5.04 <socket> ::= <integer constant> //INTERPRETED AS + DECIMAL + + 11.5.05 <host> ::= <integer constant> //INTERPRETED AS + DECIMAL + 11.5.06 <host> ::= ***** TENEX host names ***** + + 11.5.07 <object> ::= <pn> + 11.5.08 <object> ::= <string constant> + + 11.5.09 <mode> ::= READ + 11.5.10 <mode> ::= APPEND + 11.5.11 <mode> ::= WRITE + + 11.5.12 <listarg> ::= %ALL + 11.5.13 <listarg> ::= <pn>.%ALL + 11.5.14 <listarg> ::= %OPEN + 11.5.15 <listarg> ::= %ALL.%SOURCE + 11.5.16 [<LISTARG>] ::= <IDENT>.%SOURCE + 11.5.17 <listarg> ::= %OPEN.%SOURCE + 11.5.18 <listarg> ::= %OPEN.%DESC + 11.5.19 <listarg> ::= <ident>.%DESC + + 11.5.20 <pn> ::= <ident> + 11.5.21 <pn> ::= <pn>.<ident> + + 11.5.22 <ident> ::= <letter> + 11.5.23 <ident> ::= <ident> <letter> + 11.5.24 <ident> ::= <ident> <digit> + + 11.5.25 <integer constant> ::= <digit> + 11.5.26 <integer constant> ::= <integer constant> <digit> + + 11.5.27 <string constant> ::= <quote> <string conbody> + <quote> + + 11.5.28 <string conbody> ::= <nonquote> + 11.5.28 <string conbody> ::= <string conbody> <nonquote> + + + + + + +Winter [Page 29] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + +11.6 Character Set + + 11.6.01 <separator> ::= //SPACE(32) + 11.6.02 <separator> ::= //TAB(9) + 11.6.03 <separator> ::= <eol> + + 11.6.04 <special> ::= <quote> + 11.6.05 <special> ::= <superquote> + 11.6.06 <special> ::= <special1> + + 11.6.07 <letter> ::= A + 11.6.08 <letter> ::= B + ............... + 11.6.09 <letter> ::= Z + + 11.6.10 <letter> ::= a + 11.6.11 <letter> ::= b + ............... + 11.6.12 <letter> ::= z + + 11.6.13 <digit> ::= 0 + 11.6.14 <digit> ::= 1 + ............... + 11.6.15 <digit> ::= 9 + + 11.6.16 <nonquote> ::= <letter> + 11.6.17 <nonquote> ::= <digit> + 11.6.18 <nonquote> ::= <superquote> <quote> + 11.6.19 <nonquote> ::= <superquote> <superquote> + 11.6.20 <nonquote> ::= <special1> + 11.6.21 <nonquote> ::= <separator> + + 11.6.22 <eol> ::= //EOL (31) + 11.6.23 <eol> ::= <carriage return> <line feed> + + 11.6.24 <carriage return> ::= //CARRIAGE RETURN (13) + 11.6.25 <line feed> ::= //LINE FEED (10) + + 11.6.26 <quote> ::= ' //SINGLE QUOTE(44) + + 11.6.27 <superquote> ::= " //DOUBLE QUOTE(34) + + 11.6.28 <special1> ::= ! //EXCLAMATION POINT(33) + 11.6.29 <special1> ::= # //NUMBER SIGN(35) + 11.6.30 <special1> ::= $ //DOLLAR SIGN(36) + 11.6.31 <special1> ::= % //PERCENT SIGN(37) + 11.6.32 <special1> ::= & //AMPERSAND(38) + 11.6.33 <special1> ::= ( //LEFT PARENTHESIS(40) + + + +Winter [Page 30] + +RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973 + + + 11.6.34 <special1> ::= ) //RIGHT PARENTHESIS(41) + 11.6.35 <special1> ::= * //ASTERISK(42) + 11.6.36 <special1> ::= + //PLUS SIGN(43) + 11.6.37 <special1> ::= , //COMMA(44) + 11.6.38 <special1> ::= - //MINUS SIGN(45) + 11.6.39 <special1> ::= . //PERIOD(46) + 11.6.40 <special1> ::= / //SLASH(47) + 11.6.41 <special1> ::= : //COLON(58) + 11.6.42 <special1> ::= ; //SEMICOLON(59) + 11.6.43 <special1> ::= < //LEFT ANGLE BRACKET(60) + 11.6.44 <special1> ::= = //EQUAL SIGN(61) + 11.6.45 <special1> ::= > //RIGHT ANGLE BRACKET(62) + 11.6.46 <special1> ::= ? //QUESTION MARK(63) + 11.6.47 <special1> ::= @ //AT-SIGN(64) + 11.6.48 <special1> ::= [ //LEFT SQUARE BRACKET(91) + 11.6.49 <special1> ::= //BACK SLASH(92) + 11.6.50 <special1> ::= ] //RIGHT SQUARE BRACKET(93) + 11.6.51 <special1> ::= ^ //CIRCUMFLEX(94) + 11.6.52 <special1> ::= _ //UNDERBAR(95) + 11.6.53 <special1> ::= ` //ACCENT GRAVE(96) + 11.6.54 <special1> ::= { //LEFT BRACE(123) + 11.6.55 <special1> ::= | //VERTICAL BAR(124) + 11.6.56 <special1> ::= } //RIGHT BRACE(125) + 11.6.57 <special1> ::= ~ //TILDE(126) + + <EOF> + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Walter Benton 12/98 ] + + + + + + + + + + + + + + + + + + + + + +Winter [Page 31] + |