Identification with RIDs 

Use

Resources within the repository framework are identified and retrieved with resource identifiers (RIDs). These uniquely identify resources, using a hierarchically organized namespace. However, the RID alone is not always sufficient for a retrieval operation. Often a resource has variants like different language versions. In this case, additional context information helps to locate the variant. The additional information is provided by the resource context that stores data like the user involved and the logon language.

Features

RIDs have a predefined syntax, are hierarchically structured and are supplemented by information provided by the resource context.

Syntax of a RID

RIDs are comprised of a prefix followed by a path to a resource and the name of a resource. The prefix represents the path to the root directory of a framework repository. More precisely, the syntax of a RID is defined as follows:

 

 

The first slash of the above definition represents the root resource of the framework. This is a special folder containing all the repositories known to the framework. Each of the repositories within the ‘/ ‘ folder has a prefix which serves as its unique ID and represents the repository’s root resource. For example, if the ‘/’ folder contains a resource with the RID /etc this is the root resource of the etc repository.

A resource is identified by the path segment of the RID, without the query. The query element [ '?' <query> ] can add context information or select variants of a resource. However, the framework itself only responds to the query if the repository manager understands the query parameters. The query is normally passed through the framework and is resolved outside the framework. When this happens, the RID of the resource that is retrieved can be different to the RID originally passed to the framework.

The file share \\server\share is configured as a repository within the repository framework and is assigned the prefix fileserver. The file myDoc.doc is located under \\server\share\folder
In the repository framework, the file is mapped to the resource with the RID:

/fileserver/folder/myDoc.doc

The part of the RID before last slash is the path of the resource, the part after the last slash is the name of the resource.

RIDS can be either relative or absolute. Absolute RIDs start with a slash and relative RIDs with a dot. A ./ refers to the current collection, a ../ refers to the parent collection. The framework always returns absolute RIDs, except when links are involved. The use of relative RIDs is restricted to certain operations like copy and move.

Repositories sometimes have restrictions for the namespace. For example, they may limit the length of permitted paths or file names and only allow certain characters. For this reason, repositories have to supply name info which specifies the restrictions that apply to RIDs.

Hierarchical Namespace

The figure below illustrates the hierarchical structure of the repository framework namespace. It shows repositories with the prefixes etc, fileserver, documents. A parent child relationship exists between the resources in the repositories. For example, /etc/oth is a child of /etc and /etc is a parent of  /etc/oth. The hierarchical structure, combined with the slash separator, makes it possible to derive all the parent RIDs of a resource with a known RID.

Note that in the path segment of a RID, each node must be a collection. Only the name part of a RID represents an individual resource.

 

Resource Context

In addition to the RID, the resource context also supplies information for the retrieval of resources. While the RID specifies which resource to retrieve, the resource context specifies details like who wants to retrieve the resource and the language. These details can, in turn, affect howthe resource is retrieved.

The resource context contains at least the principal (user, group or role) for whom the application wants to retrieve the resource. On the basis of this information, repositories can react in different ways. A repository that supports access control can check the user against the access control list to determine whether or not to permit access. Another repository might find out the language of the user and then retrieve a version of the resource with the appropriate language.