Update split catalog namespace docs

Author: jackye1995

docs/mkdocs.yml

@@ -68,4 +68,3 @@ extra:
 
 extra_javascript:
   - https://unpkg.com/mermaid@10/dist/mermaid.min.js
-

docs/src/catalog/dir/index.md

@@ -112,13 +112,13 @@ The `__manifest` table has the following schema:
 
 **Primary Key**: The `object_id` column is the [unenforced primary key](https://lance.org/format/table/#unenforced-primary-key) for the manifest table. Implementation of this spec must always enforce the primary key uniqueness using features like Lance merge insert with primary key deduplication.
 
-**Schema Extensibility**: The `__manifest` table schema may include additional columns beyond those listed above. Extensions like [partitioned namespaces](../partitioning-spec.md) add columns for efficient filtering. Implementations should preserve unrecognized columns during updates.
+**Schema Extensibility**: The `__manifest` table schema may include additional columns beyond those listed above. Implementations should preserve unrecognized columns during updates, since extensions may add columns for filtering or other metadata-driven behaviors.
 
 ### Root Namespace Properties
 
 In V2, the root namespace is implicit and does not have a row in the `__manifest` table. Instead, root namespace properties are stored in the `__manifest` Lance table's metadata map. Properties are stored as key-value pairs where the key is the property name and the value is a UTF-8 encoded byte array.
 
-For example, a partitioned namespace stores its `partition_spec_v1`, `partition_spec_v2`, and `schema` properties in the `__manifest` table's metadata.
+For example, implementations may store catalog-level properties in the `__manifest` table's metadata.
 
 ### Manifest Table Indexes
 

docs/src/layout.png

@@ -11,7 +11,16 @@ that frequently appear in other similar data systems to allow easy integration w
 
 Here is an example layout of a namespace:
 
-![Namespace Layout](../layout.png)
+```text
+Root namespace
+├── Namespace "cat2"
+│   └── Namespace "cat5"
+│       └── Table "t1"
+├── Namespace "cat3"
+└── Namespace "cat4"
+    ├── Table "t3"
+    └── Table "t4"
+```
 
 ## Parent & Child
 
@@ -83,4 +92,4 @@ A table `[catalog1, database2, table3]` is at level 3, and its identifier `catal
 If every table in the root namespace are at the same level `N`, the namespace is called **leveled**,
 and we say this namespace is a `N`-level namespace.
 For example, a [Directory Catalog](../catalog/dir/index.md) is a 1-level namespace,
-and a Hive 2.x namespace is a 2-level namespace.
+and a Hive 2.x namespace is a 2-level namespace.

docs/src/namespace/object-relationship.md

@@ -4,7 +4,7 @@ This document describes how the Lance Directory Catalog implements the Lance Nam
 
 ## Background
 
-The Lance Directory Catalog is a storage-native catalog that stores tables in a directory structure on any local or remote storage system. For details on the catalog design including V1 (directory listing), V2 (manifest), and compatibility mode, see the [Directory Catalog Format Specification](../catalog/dir/index.md).
+The Lance Directory Catalog is a storage-native catalog that stores tables in a directory structure on any local or remote storage system. For details on the catalog design including V1 (directory listing), V2 (manifest), and compatibility mode, see the [Directory Catalog Format Specification](../../catalog/dir/index.md).
 
 ## Implementation Configuration Properties
 
@@ -16,7 +16,7 @@ The **manifest_enabled** property controls whether the manifest table is used fo
 
 The **dir_listing_enabled** property controls whether directory scanning is used for table discovery (V1). Defaults to `true`.
 
-By default, both properties are enabled, which means the implementation operates in [Compatibility Mode](../catalog/dir/index.md#compatibility-mode).
+By default, both properties are enabled, which means the implementation operates in [Compatibility Mode](../../catalog/dir/index.md#compatibility-mode).
 
 Properties with the **storage.** prefix are passed directly to the underlying Lance ObjectStore after removing the prefix. For example, `storage.region` becomes `region` when passed to the storage layer.
 
@@ -173,7 +173,7 @@ In **V2**:
 3. Further filter to rows where `object_id` has exactly one more level than the namespace
 4. Return the list of table names
 
-When **both V1 and V2 are enabled** (the default [Compatibility Mode](../catalog/dir/index.md#compatibility-mode)),
+When **both V1 and V2 are enabled** (the default [Compatibility Mode](../../catalog/dir/index.md#compatibility-mode)),
 the implementation performs both queries and merges results, with manifest entries taking precedence when duplicates exist.
 
 **Error Handling:**
@@ -189,7 +189,7 @@ The implementation:
 1. Locate the table:
      - In V1, check for the `<table_name>.lance` directory
      - In V2, query the manifest table for the table location
-     - When both V1 and V2 are enabled (the default [Compatibility Mode](../catalog/dir/index.md#compatibility-mode)),
+     - When both V1 and V2 are enabled (the default [Compatibility Mode](../../catalog/dir/index.md#compatibility-mode)),
        first check the manifest table, then fall back to checking the `.lance` directory
 2. Open the Lance table using the Lance SDK
 3. Read the table metadata and return:
@@ -231,7 +231,7 @@ In **V2**:
 3. Keep the table files at the storage location
 4. Return the table location and properties for reference
 
-When **both V1 and V2 are enabled** (the default [Compatibility Mode](../catalog/dir/index.md#compatibility-mode)),
+When **both V1 and V2 are enabled** (the default [Compatibility Mode](../../catalog/dir/index.md#compatibility-mode)),
 first check the manifest table, then fall back to checking the `.lance` directory.
 If found in manifest, follow V2 behavior; otherwise follow V1 behavior.
 
@@ -260,7 +260,7 @@ In **V2**:
 3. Delete the table directory and all its contents from storage
    (failure here does not affect the success of the drop since the table is no longer reachable)
 
-When **both V1 and V2 are enabled** (the default [Compatibility Mode](../catalog/dir/index.md#compatibility-mode)),
+When **both V1 and V2 are enabled** (the default [Compatibility Mode](../../catalog/dir/index.md#compatibility-mode)),
 first check the manifest table, then fall back to checking the `.lance` directory.
 If found in manifest, follow V2 behavior; otherwise follow V1 behavior.
 

docs/src/namespace/supported-catalogs/lance-dir.md

@@ -4,7 +4,7 @@ This document describes how the Lance REST Catalog implements the Lance Namespac
 
 ## Background
 
-The Lance REST Catalog provides access to Lance tables via a REST API. For details on the API design, endpoints, and data models, see the [REST Catalog API Specification](../catalog/rest/index.md).
+The Lance REST Catalog provides access to Lance tables via a REST API. For details on the API design, endpoints, and data models, see the [REST Catalog API Specification](../../catalog/rest/index.md).
 
 ## Implementation Configuration Properties