名前空間は、マウントされたファイルシステムのようなものです（ドメインの説明も御覧下さい）。 名前空間には、階層ツリー構造の情報があり、その構造はディレクトリとファイルを類推する事が出来るでしょう。 慣例的なファイルシステムの構造・コンテンツに加え、名前空間には、 アプリケーションのセキュリティポリシーを動的に規定する、 action (つまり、read や write) や subject (つまり、userやgroup) があります。

名前空間は、必然的に、自己完結型です（あるいは、独立しているとでも言うべきでしょうか）。 これの意味するところは、名前空間が別の名前空間への参照やリンクを持つ事が出来ない、という事です。 名前空間は、概してアプリケーション毎に割り当てられ、事実上、データ及びセキュリティコンテキストを他のアプリケーションのそれとは隔離しています。

階層のノードは、URI (Unique Resource Identifier)を使って、階層の中に置かれます。 URIを、慣例的なファイルシステムの中のファイルパスと類推する事が出来るでしょう。 URIの例を挙げると：/users/john/documents/my_document.txt。 見て分かるように、所与のパスでノードを分ける際にスラッシュ("/")を使います。

名前空間には、オブジェクト管理を任されている異なる7つのヘルパ（よく言われるのは、high-level servicesという名前です）があります：

• Structure
• Security
• Lock
• Content
• Macro
• Index
• Process

ノードがどこにあろうとも、storeがどのように物理的に格納されていようとも、 これらの高レベルサービスによって、アプリケーションが一定のやり方でノードにアクセスする事が出来るようになります。

クライアントが使えるヘルパとそれとは異なるオブジェクトは、 クライアントアプリケーションに提供されるAPIです。 ドキュメント内の Slide API セクションに、より詳細の情報があります。

Slide では、オブジェクトがどのように格納され、ロックされるか、等を制御する低レベルサービスを定義する事が出来ます。 異なる種類のオブジェクトは、それらのオブジェクトがどうアクセスされ、何を表しているか、等に依存するような、異なる処理の実装が必要だからです。

異なる2種類のサービスがあります：

• Descriptors store：格納構造・ロック・メタデータ等を扱う役割があります
• Content store：コンテンツの格納を扱う役割のみがあります

少量のデータの管理とインデックスを非常に効率よく行うレポジトリ（リレーショナルデータベースが良い例でしょう）がある一方で、 データの大きなチャンクを格納するのに相応しいレポジトリ（ファイルシステム等）がある、 と言う事は極めてわかりやすい事なので、この両者（2つのstore）の違いが存在しているのです。

Slide 内では、全てのオブジェクトが異なる種類の低レベルサービスを背後に持つ事がありえます。 例えば、 遠隔のLDAPディレクトリに格納されているオブジェクトがある一方で ローカルのSQLデータベースに格納されているオブジェクトがある場合があります。 このように、名前空間のコンテンツは、いくつかの異なるdescriptors store／content store に 分散され得るのです。

低レベルサービスを名前空間の個々のノードにマッピングするSlide設定ファイルを使って、どのようにオブジェクトが格納されるかを選ぶという事は、管理者の一存にかかっています。

サービスは、名前空間内でノードの属性値となります。 このマッピングは、自動的にサブノードによって継承されます。 ここで、ある名前空間がどのように異なるサービスにマッピングされるかの例を示します：

異なる低レベルサービスへの名前空間のマッピング

この例では、異なる3つのサービスがマッピング化されています。 全てのactionsが一緒になって格納され（メモリstoreの可能性が高い）、 全てのfilesが特定のstoreに格納されています（ここでは、ファイルシステム）。 /usersはSQLデータベースにマッピングされています。