\
URN 对建立现代的、适宜 Internet 的应用程序是至关重要的，但人们对它还远远不够熟悉。目前还没有一种通用的方式来间接访问 URN 以查找它所标识的资源。URN 的语法结构保证了 URN 跨多个组织的唯一性。其语法如下所示：
\
架构设计指南的内容如下： 使用和定义命名空间 (URN)
使用命名空间定义属性和内容类是一种好办法。命名空间的作用包括：
? 有助于确保属性和类的名称是全局唯一的；即，解决识别和冲突的问题。如果您有多个应用程序在同一时间部署，或者独立软件开发商 (ISV) 在一个大型组织中部署他们的应用程序时，这一点都是特别重要的。
? 指示“拥有”属性或类定义的个体或组织。
在随 Exchange 2000 提供的预定义属性和类中，您会发现有许多不同类型的命名空间：
? ? ? ?
urn:schemas:httpmail:
urn:schemas-microsoft-com:exch-data: urn:schemas-microsoft-com:office:office
第一个示例是一种通用的广为接受的命名空间，目的是为了增强各种架构感知应用程序间的互操作性。 接下来的两个是专用 URN。如果您希望为您的应用程序创建一个类似的命名空间，您可以创建 urn：schemas-mycompanysdomain-com:myapplication:。
第二个和第三个命名空间的差别就在于：第二个命名空间的结尾有一个命名空间分隔符而第三个命名空间没有。如果命名空间以分隔符“:”或“/”结尾，将创建属性或内容类名称，且属性名附于命名空间后。例如，第二个命名空间中的一个属性是 urn：schemas-microsoft-com:exch-data:ismultivalued。 如果命名空间不以分隔符结尾（如第三个示例），则该命名空间中将创建属性名，命名空间与属性名之间有一个符号“#”。例如，第三个命名空间中的一个属性是 urn：schemas-microsoft-com:office:office#Author。
最后一个命名空间示例显示如何将 URL 用作命名空间。您应当从您拥有或已注册的 URL 中选择基于 URL 的命名空间。这将有助于保证命名空间的唯一性。URL 用作命名空间时，最后一个分隔符为字符“/”。 不应向您不拥有的命名空间中添加属性或内容类。例如，向 或 DAV: 命名空间添加属性就不好，而应当为您的内容类和属性创建自己的命名空间。 进行属性定义
Web 存储系统本身对属性名称中可使用哪些字符没有特殊的限制。但是，最好还是遵守以下一些约定：
? 应当使用命名空间来创建属性并加上一个标识符（如上文所述）。例如， urn:schemas-sample-com:engineering:eco.
? ?
属性应当是格式正确的 URI。
属性名称中不应有空格，因为 XML 不支持在元素名称中使用空格，因此 HTTP-DAV 也不支持。
定义自定义内容类
在定义了这些自定义属性之后，下一步就是定义您的自定义内容类。首先，您需要为应用程序选择一个文件夹，用来存储架构信息。您可以将这些信息存储在您的应用程序数据所在的同一文件夹中，但我们强烈建议您使用一个不同的子文件夹，我们称之为架构文件夹。如果您在正定义的架构不是针对某一个应用程序的，您可以在相关的公共存储区里的高层架构文件夹中定义它。
存储架构定义的位置和组织架构定义的方式由您决定。但是，在下一部分中，我们将推荐一组方式，指导您如何组织文件夹结构以及如何确定对一组特定应用程序数据应用哪一个架构定义。
下面的关系图阐释了使用一个 Exchange 2000 SDK 工具（即：Web 存储系统架构设计器）来自定义内容类的一个示例。我们建议您使用该工具或类似工具来定义自定义内容类的定义和属性定义。
图 7. 示例：架构设计 考虑内容类的继承性
您当然可以从头开始定义一个全新的内容类。不过，多数内容类都可以扩展（“继承”）现存的内容类。扩展内容类意味着已扩展的（派生的）内容类实例的所有属性也存在于扩展中的（基本的）内容类实例中。这一概念与 C++ 这样的面向对象 (OO) 的编程语言中类继承的概念相似。
图 10 显示一个简单的继承方案。扩展文档类意味着任何可在文档类实例上执行的代码或操作都可以在 expensereport 类实例上执行。
图 8. 简单内容类继承
图 9. 带有多个继承关系的内容类
内容类也可扩展为多个内容类。在图 11 中，我们还能看到一个 expensereport 类，它具有 totalcost 和 approvastate 两种属性。但在这一方案中我们希望有作为文档的一个特定类的费用报告和作为消息的一个特定类的费用报告。因此，我们创建一个 exprensereport 类来扩展该类。然后创建一个
exprensemessage 类和一个 exprensedocument 类，它们自己没有其它属性。Expensemessage 扩展了 expensereport 和 message，而 exprensedocument 扩展了 exprensereport 和 document。现在，理解 message 类的应用程序就可以理解 expensemessage 类的一些属性，而把其余属性当作自定义属性。理解 document 类的应用程序就可以理解 exprensedocument 类的一些属性。
有关架构设计的详细信息，请参考 Exchange 2000 SDK 以及白皮书“Web 存储系统架构：使用和最佳方法指南。”
Web 存储系统文件夹结构的最佳方法
Web 存储系统为设计文件夹结构提供了很大的灵活性。架构定义项可置于特定存储区内的任一文件夹中，并用于为您的应用程序定义架构。通过合理设置不同文件夹的 schema-collection-ref 和 baseschema 属性，您可以将这些定义引入到范围中来。
为了避免设计和管理应用程序架构太过复杂，应规划并组织好您的架构信息。例如，可以选择在您指定为架构文件夹的应用程序文件夹的顶层下创建文件夹。设计文件夹结构有许多种方式。以下步骤概述了这一过程。
考虑以下各项：
? 逻辑模型的复杂程度：正如上文所述，设计存储区的架构有许多方式。在作出最终设计决定前应当考察所有相关的信息和设计选项。
? ? ?
物理模型的复杂程度：您应当考虑到维护复杂文件夹结构的困难程度。 性能影响：将在以后的部分中讨论。 重复使用和共享架构。
将架构文件夹与其它类型的文件夹区分开来，例如：
? ? ?
应用程序文件夹：包括 ASP 页面、HTML 页面、Web 存储系统窗体等等。 数据（内容）文件夹：包括数据项或文档。 窗体注册文件夹：包括窗体注册项。
通常，特定应用程序的架构定义将置于它们自己的文件夹中。将应用程序文件夹和数据文件夹分开也是一种好方法。正如上文所述，特定文件夹的 schema-collection-ref (SCR) 和 baseschema 属性确定架构范围。设计文件夹结构有许多灵活的方式。 文件夹结构的示例如下：
? 一个简单的应用程序可以有一个包含应用程序文件（ASP、HTML 页面）和数据项的文件夹，以及一个架构文件夹。
? ?
稍微复杂点的应用程序可以分别有单独的应用程序文件夹、数据文件夹和架构文件夹。 架构文件夹可以有不同的级别，如顶级架构文件夹包含在同一根下运行的所有应用程序。也可以采用一系列架构文件夹，每个架构文件夹通过 SCR 引用另一个架构文件夹。
定义架构文件夹。
? ?
定义常用的内容类和属性定义。
定义窗体注册。（这可能在一个单独的窗体注册文件夹中。）
创建架构文件夹时，您必须确定这些文件夹的范围。即，某一给定的架构文件夹适用于哪些数据文件夹？任意数量的数据文件夹可以使用一个架构文件夹。反之，在多个架构文件夹中定义的架构可以应用于一个数据文件夹。
正如上文所述，schema-collection-ref 是一个可在数据文件夹上设置的属性，用来指示在查找相关属性和内容类定义时应首先搜索哪个架构文件夹。baseschema 属性则形成一个架构文件夹的树形结构来搜索架构定义。在这个架构文件夹的逻辑树中，每个节点都可有许多子节点。这个架构文件夹的逻辑树可以（并且通常会）与存储区中文件夹的物理布局不同。相对于给定的数据文件夹，schema-collection-ref 属性指示搜索始于哪个架构文件夹。
? 定义应用程序和数据文件夹。
? ?
如果需要，将 schema-collection-ref (SCR) 属性指向架构文件夹。 使用 baseclass 和 expected-content-class。
SQL 与 Web 存储系统
这一部分我们考察 SQL 关系型数据库和 Web 存储系统间的主要差别；讨论何时使用 SQL 以及何时使用 Web 存储系统；并提供一套指南，用于从已有的 SQL 数据库向 Web 存储系统移植数据。
使用Web存储系统设计知识管理解决方案
