IRAC Preface | 1 Introduction | 2 General Design Objectives | 3 General Syntax and Semantics of the Abstract Specification | 4 Object Management System | 5 Program Execution Facilities | 6 Input and Output | 7 Protection and Security | 8 Requirements for Tool Management and Services for Tools | 9 Ancillary Requirements | 10 Definitions | Submission of Comments

4.3 Identification

The term "identification" refers to the process of specifying objects, relationships, attributes and their types for the purpose of operating on them by some designated operation.

4.3A Identification. The PCIS shall provide that each object, attribute, relationship, object type, attribute type and relationship type be unambiguously identifiable.

In order to carry out operations on representations of objects, on representations of relationships, or on attributes, it is necessary to specify the object, relationship, or attribute (or set of these) upon which the operations are to be performed and to specify the operation to be performed. The objects, relationships, and attributes to which the operations are to be applied are specified by identification.

4.3B Identification Conflict Resolution. The PCIS shall provide mechanisms to resolve identification conflicts that might arise when independently developed tools are to be installed on top of a PCIS implementation.

The PCIS must be able to accommodate both of the following cases:
  1. Where two tools can identify the same attribute or relationship by different names
  2. Where different attributes or relationships may be identified by the same name

4.3C Identification Methods. The PCIS shall support identification by at least the following methods:

a) Identification of one or more "start" objects, the identification of a relationship type and the specification of a predicate involving attributes or attribute types associated with that relationship type or with its associated object types. This method shall identify those objects which are related to the identified start object(s) by relationships of the given relationship type and for which the predicate is true. Subject to the security constraints of Sections 7.2 and 7.3, all relationships and objects shall be capable of identification via this method, and all attributes and attribute types (except attributes whose values can be used as bulk data files) shall be permitted in the predicates. Key attributes should be used in a distinguished way in identification.

b) By a reference to an object (see Requirement 4.3E).

c) Identification of a "start" object, the specification of a predicate involving object types, attributes or attribute types. This method shall identify those objects which are components of the start object and for which the predicate is true.

d) Identification of a "start" object, the specification of a predicate involving object types, attributes or attribute types. This method shall identify those objects of which the start object is a component and for which the predicate is true.

e) Identification of an object using a globally unique identifier as an explicit or implicit unchangeable attribute of each object, unique for all time.

A major function of the OMS is to provide a name space for the objects that it manages.

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.

4.3D Exact Identifiers. The PCIS shall provide exact identities for all objects. The PCIS shall support exact identities for all relationships. The exact identity shall be unique within an instance of a PCIS implementation, and the PCIS shall support a mechanism for the utilization of exact identities across all PCIS implementations.

An exact identity which is universally unique for all time is possible, practical and useful. There have been arguments in the past of the possibility and practicality of globally unique identifiers.

4.3E References to Objects. The PCIS shall provide a mechanism for referencing objects, in particular:

a) A reference shall identify a single object until the reference is changed or the object is deleted. If the object is deleted, all subsequent use of an unchanged reference shall not identify any other object.

The reference uniquely identifies the same object without necessarily impeding its use. It may track the object while the object is moved, has its pathname sequence changed, has its key attributes changed, is otherwise renamed, and has its contents change.

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.

b) It shall be possible to make a sequence of accesses to a referenced object with access controls checked only once, where this is compatible with the security requirements of Sections 7.2 and 7.3.

This is essentially a performance issue. It has been addressed here because it is felt that a significant proportion of the access operations will fall into this category. In effect this mandates checking of the access controls when the reference is created, not every time it is used.

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

c) The PCIS shall support the ability to associate and dissociate stability requirements with a reference. The stability requirement applies to the referenced object and at least includes that the object is not deleted while the stability requirement persists.

Stability requirements are especially required in multi-processing environments. As with references, one tool may be performing processing steps which assume the continued validity of reference to an object while another tool, user, or system action deletes or makes an object unobtainable, thus compromising the integrity of the first tool's continued processing.

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

4.3F Interprocess Identification. It shall be possible for two cooperating processes to identify objects of mutual interest.

One particular requirement here is to tell a child process, which is to do some operation for the parent, on which object it is to operate. For example, a CLI may need to tell a compiler it has invoked which object to compile. Another example is that of a spooler: it is necessary for any process invoking a print spooler to inform it of the object to be printed.

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.

4.3G Query.

a) PCIS shall provide common query access facilities to query collections of objects identified by predicates of an arbitrary complexity. Such facilities shall include at least a programmatic interface and a query language. The predicates used in such queries should allow selection according to relationships and to attributes of both objects and relationships.

The navigational identification means are expected to be the most frequently used within typical software engineering tools and by users in the identification of their tools and objects under development. There are however situations where global queries need to be made on the whole database or on all objects related to a given project. Such queries should be preferably written in a common language permitting the exchange and portability of scripts containing queries.

b) PCIS shall allow query facilities (including those of PCIS) to be built as a service on top of the more basic identification facilities.

The complexity of a query tool is potentially high. It should be possible to design the query language so that it can be ported as a separate tool or common service, on top of the basic data manipulation facilities. According to the availability (or not) of such a service, a PCIS implementation shall be therefore compliant (or not compliant) to a certain level. Such an approach would also allow for a separate evolution/maintenance of the query language definition service.

Go forward to Section 4.4, Data Manipulation.