A Namespace is like a mounted filesystem (see also domain description). It contains a hierarchical tree of information, which can be analogous to directories and files. In addition to traditional file system structure and content, a namespace can contain actions (ie. read, write) and subjects (ie. users and groups), which define the dynamic security policies of an application.

Namespaces are necessarily self-contained (or independent, if you want). What this means is that a namespace cannot reference or contain links to another namespace. A namespace is typically assigned per-application, which effectively isolates its data and security context from those of other applications.

Nodes in the hierarchy are located within a hierarchy using a URI (Unique Resource Identifier). A URI is analogous to a file path in traditional file systems. An example of URI is: /users/john/documents/my_document.txt. As you can see, the slash ("/") is used to separate nodes in the given path.

There are seven different helpers (or high-level services, as they are often called) offered to manage objects in a namespace:

	Structure
	Security
	Lock
	Content
	Macro
	Index
	Process

These high-level services allow an application to access nodes in a uniform fashion, no matter where the node might be located, or how the store is phisically stored.

The helpers and the different objects they make available to the client are the API provided to the client application. More details are given in the Slide API section of the documentation.

In Slide, it is possible to define low-level services to control how objects are stored, locked, ... This is because different kinds of objects might need very different execution implementation, depending how they are accessed, what they represent and so on.

Two different kinds of services exist :

	Descriptors store, which are responsible for storing structure, locks, metadata, ...
	Content store, which is only responsible for storing the content

A distinction has been made, because it's easy to see that while some repositories are very efficient at managing and indexing small amounts of data (relational databases are a good example of this), others are best for storing big chunks of data (filesystem, ...).

Within Slide, every object can possibly have a different kind of backing low-level service. For example, some objects might be stored in a remote LDAP directory, while others could be stored in an local SQL database. Thus, the content of a namespace can be distributed across several different descriptors/content store.

It is up to the administrator to choose how objects will be stored using the Slide configuration file, which maps low-level services to individual nodes in the namespace.

Services are attributed to nodes in the namespace. This mapping is automatically inherited by sub-nodes. Here is an example of how one namespace might be mapped into different services:

Namespace mapping onto different Low-Level Services

In this example, there are four different service mappings. All actions are stored together, possibly in a memory store, all files are stored in a specific store (possibly in a remote FTP file server), while paul's files could be stored on his own computer. The rest (/, /users and /users/root in the example above) could be mapped into an arbitrary SQL database.