Human users of the OMS need to be able to refer to objects and operations by using names that have some mnemonic or connotative meaning to them. The OMS establishes a domain or region over which names are applicable or valid, which may in fact span several physical computer systems. There may be syntactic rules that determine the validity of a name.
Because there is only a limited number of meaningful names and users tend to duplicate each other's choices in naming their own objects, the name space must have some internal organization structuring by which names are mapped to objects. That is, a user must be able to specify a local area of the complete name space into which his names are mapped. Another user in another local area would then be able to use the same names for another set of objects.
The problem with the use of the term "name" and the reason why this term is avoided in the IRAC is the implication that the concept is associated with a character string. In contrast, the terms "identity" or "identification" are used to imply that selection of something may depend not only on a character string (for example), but also on the context in which it is used. There is an analogy here with block structured languages; a name, for example "I", may be used in different places, and may refer unambiguously to different things, depending on the scope rules.
Choice of the form of user-specified names should be biased heavily toward user convenience, at the possible expense of additional processing needs in the OMS. "User-friendly" features such as lengths on the order of a full line, mixed case that is retained but not significant, and embedded blanks in composite names should be considered. The typical user will deal with many objects in the course of a day's work; he or she must be able to assign names that are both meaningful and easy to recall.
The OMS may provide particular object types, attributes and relationships whose purpose is the support of user naming. For example, the common concept of a system of tree-structured directories and files could be implemented by directory objects and child relationships from them to other directories or to files.
The form of user-specified names is not necessarily a consideration of the PCIS; there need not be a direct mapping between how names are specified by the user to tools and how those tools specify them to the PCIS. For example, a tree-structure implementation might have user-specified names in UNIX form: a top-down list of node-names separated by slashes. The corresponding PCIS mechanism might specify names to be variable-length arrays of simple name strings. The tools built on this PCIS mechanism would have to parse the former format and map it into the latter.
If the PCIS designers choose to specify the external form of names, they should try to avoid restrictions based on pre-conceptions of the form of the user interface. For example, the idea of embedded blanks in names is horrifying to most people because of the problems involved in parsing a command string. However, in a menu-selection or icon-based user interface, these problems do not arise. Names are usually pointed to, not typed; when they are typed, it is in response to a prompt for a name, to be terminated by a carriage return that makes it possible to isolate the name despite embedded blanks.
Users need to be able to name groups of things, such as "all files in directory x". As with the form of user names, it is not clear if this need will be fulfilled by the PCIS or by higher-level support.
The general requirements for human usable and flexible identification have been set out above. In terms of the specific data model, a specific method for identification of representations of objects and relationships is required here.
The start object itself, of course, has to be identified somehow. Requirement 4.3A ensures that this is possible in some way, without requiring any particular way of doing so.
Requirement 4.3E below, stating that a reference shall identify a single object, corresponds to the ability to use a reference as a method of identification.
Identifications (as defined here) may result in a set of objects being identified. It is up to the PCIS designers to specify the effect of identifying more than one object; for example, some operations may be forbidden when an attempt is made to apply them to more than one object. Key attributes are distinguished, because appropriate use of them can result in identifying at most one object instead of a set.
Additional methods are not, of course, ruled out. One possible additional identification method is the ability to identify all objects of a given type, subject to an appropriate predicate. Such an identification method is not required, although it was discussed. There were inconclusive arguments both for and against it, and it was determined to be best left to the PCIS designers.
Another possible additional method is an analogue of Requirement 4.3C(c) above which would identify all relationships which are components of the start object conforming to the predicate. Inclusion of such a requirement was felt to be premature since details of the semantics of relationships as components of objects have not been specified here.
Obviously when the reference ceases to exist (by whatever means is appropriate for the PCIS concept which satisfies this requirement) the object is no longer identified by the reference. It is up to the PCIS designers to decide whether a reference outlives the process or not. The model on which the requirements are based is that a reference would belong to a process and, hence, would not outlive the process. However, it is not intended to rule out other solutions, if such are considered appropriate by the PCIS designers (for example, some references might belong to a transaction). It is not the intention of this requirement to create a need for an infinite source of references for use by processes.
The reference in the requirement to security is an alert to the fact that all operations may not be possible on any particular object. Thus, in some security models, it is possible to write objects which cannot subsequently be read (for example, writing a secret object from a confidential process). Similarly it is possible to read objects which cannot be amended (for example, reading an unclassified object from a confidential process).
There are two approaches to the problem of object stability. Either the tool writer can explicitly accommodate the possibility of object deletion within the tool, or, in order to simplify the code, he can ensure that the object cannot be deleted. This mandates provision of facilities to support the second option.
The PCIS designers may choose that the stability requirement ceases when the reference no longer refers to the object or when the process creating the reference ceases to exist. However, it is left open to the PCIS designers to choose some other lifetime for the stability requirement. (This may particularly be needed in the context of transactions).
In some circumstances a process may communicate by passing a pathname to another, but passing a pathname will not always be satisfactory. Firstly, the other process may be working within a different schema, so it might use different names within a path. Secondly, the sending process may not know the pathname of the objects in which it is interested; i.e., it may have used references to objects (see earlier requirement) and there is no requirement for the ability to generate a pathname to an object. In the circumstances where a pathname cannot be used (and the print spooler is a good example), PCIS must provide an alternative mechanism. This may be based on, for example, the exact (or unique) identifier (see Requirement 4.3C(e)). Note that in the case of a print spooler in a multi-level secure environment, the mechanism must be unsubvertible, such that a process cannot masquerade as another process or interfere with the print queue either to obtain a print-out of the information with the wrong security label on it, or to obtain print-out of the wrong information, or to prevent print-out of the information.
Go forward to Section 4.4, Data Manipulation.