Sharepoint

使用自定义内容类型对数据管理进行标准化

Pav Cherny

概览:

• 使用 SharePoint 进行内容生命周期管理
• 创建文档信息面板
• 通过 InfoPath 来编辑 Office 和 SharePoint 文档

下载这篇文章的代码: ContentTypes2008_02.exe (779KB)

企业环境中存在大量文档及其他内容项目，企业要

以集中、可重用的方式管理文档、文档元数据和文档行为，面临着业务和技术方面的挑战。利用 Microsoft® Office SharePoint® Server 2007，组织内的各个团队可以共享网站上的工作区、文档库以及列表，有利于促进公司范围内的协作。

使用 SharePoint 2007，可以通过内容类型来标准化内容及生命周期特征的各个方面。站点内容类型是可以独立于任何特定站点集合、站点、列表或文档库而建立的元数据定义。这使您可以在公司范围内建立统一的属性、工作流、信息管理策略及其他元素，同时还允许各个部门或站点所有者自定义特定用途的内容类型。

在本文中，我将向您介绍如何使用在 Windows® SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 中引入的全新 SharePoint 内容模型来构建基于常规特征的企业内容层次结构。这些内容层次结构不但可以在全局级别统一应用元数据、工作流和信息管理策略，同时还具有一定的灵活性，可以在站点集合、站点、文档库和列表级别适应特有的内容管理需求。

为阐明 SharePoint 内容类型某些较低级别的情况，我在附属材料中提供了许多自定义工具，考虑到您可能会需要根据特定需求扩展这些工具，我还随附了源代码。不过请记住，这些工具尚未经过全面测试，因此不要用在生产系统中。您可以从**《TechNet 杂志》网站下载代码，网址为 technetmagazine.com/code08.aspx。

内容生命周期和内容类型定义

SharePoint 资源

• InfoPath 团队博客
• Office SharePoint Server 2007 中的工作流
• TechNet 网络广播：在 SharePoint Server 2007 中安装和配置搜索
• InfoPath Forms Services

在组织中管理文档和其他内容时，有许多细节需要考虑。除此之外，还必须定义在创建、发布、存档和释放内容时，哪个人或哪个流程需要执行哪项操作。对组织而言，通常还需要开发用于内容创建的特定模板、定义角色以将责任和访问权限分配给用户、提供版本控制、监控兼容性、存储和存档、定义元数据等等。

无论某个特定内容生命周期多么复杂，SharePoint 内容模型均可找出某些常规特征和典型阶段，它们可以决定应该如何处理单个内容项目。例如，您可以通过模板和输入表单来组织内容创建，通过元数据来组织内容显示和搜索。您还可以使用编辑、批准或其他工作流需求、存档需求、过期时段以及适用的信息管理策略来区分单个内容片段。有些内容可能不需要任何特殊模板或者可能永远不需要存档，但即使这样它们也属于生命周期特征，会继续进入下一阶段以区分这些项目与其他项目。

SharePoint 内容模型允许您定义独立的内容类型并建立层次结构关系。在层次结构关系中，子项从父内容类型继承常规特征，并根据需要添加特定的特征。

要说明这一点，最佳方法就是检查 SharePoint 的内置内容类型。WSS 3.0 和 MOSS 2007 包括了许多典型项目的预定义内容类型，它们可存储在文档库或列表（包括文档和任务）中。您可以在 SharePoint 服务器上的 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes 文件夹中找到这些标准内容类型的定义。在那里您会发现一个名为 feature.xml 的指令清单文件。请看一下此文件，您会注意到 SharePoint 将标准内容类型定义作为具有站点集合范围 (Scope="Site") 的隐藏功能 (Hidden="TRUE") 实现，还可以注意到包含实际内容类型元素的 Element 指令清单文件为 ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />)。

如果您有兴趣了解有关 SharePoint 功能的更多信息，建议您阅读一下《MSDN® 杂志》中 Ted Pattison 的 Office Space 专栏，里面有一篇题为“SharePoint 的功能”的文章，网址为：msdnmagazine.com/issues/07/05/OfficeSpace。

现在，让我们在记事本中打开 ctypeswss.xml 文件来检查标准内容类型，忽略它们在 SharePoint 用户界面中的可见性。请勿修改 ctypeswss.xml。 如果您打算对 ctypeswss.xml 进行编辑以向标准内容类型中添加一些新字段或使隐藏的内容类型变为可见，以便 SharePoint 用户可以使用它们来派生新内容类型，那么请注意，这通常是没有必要的。而且这还会导致配置不受支持，甚至导致以后安装的 Service Pack 可能覆盖您的自定义内容并破坏内容管理解决方案。

较好的做法是将所需的内容复制到新的元素指令清单文件中、根据需要添加自定义内容，然后将自定义内容类型部署为具有站点集合范围的新功能，以便它们可供站点集合中的所有站点使用。

在 ctypeswss.xml 中指定的基于协作应用程序标记语言 (CAML) 的 System 内容类型定义如下所示：

<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>

Group 和 Sealed 属性显示 System 内容类型已被隐藏和密封，因此不能在 SharePoint 用户界面中对其进行更改。System 内容类型只有一个 FieldRef 元素，它引用一个名为 ContentType 的内置站点列。这是最高级别的抽象。所有其他 SharePoint 内容类型都从 System 内容类型继承此属性。在此方法中，SharePoint 可确保存储在任何文档库或列表中的所有内容项目都共同拥有此属性。

图 1 显示了本文附属材料中提供的 ContentTypeHierarchy Web 部件，它以更加直观的方式对层次结构进行了说明。System 位于所有其他内容类型的根部，然后是 Item 等等。例如，Item 内容类型建立了下一级别的详细信息。如果检查 ctypeswss.xml，您会看到 Item 定义了一个单一的元数据字段，该字段引用了一个名为 Title 的站点列。通过这种方式，较低级别的所有内置内容类型都具有了 Title 属性。

图 1** WSS 3.0 内置内容类型层次结构 **(单击该图像获得较大视图)

继承的字段也可以删除，正如 ctypeswss.xml 中的 Document 内容类型定义所演示的那样。Document 内容类型包括多个对应的 RemoveFieldRef 元素，但是您可能希望 Title 字段按原样保留在您的自定义内容类型中，因为在 SharePoint 文档库和列表视图中可以通过 Title 列访问编辑控件箱 (ECB) 下拉菜单。

ctypeswss.xml 中的 Far East Contact 内容类型很好地说明了如何重命名继承的字段。搜索 0x0116（这是对应的内容类型 ID），然后检查 FieldRef 元素的属性 Name="Title"，以了解如何使用 DisplayName 属性来重命名用户界面中的字段。在这个特定的示例中，DisplayName 属性将用户界面中 Title 字段的名称更改为由 "$Resources:core,Last_Name;" 引用的本地化的数据值。

如果进一步查看图 1，您会看到 ContentType 元素的 ID 属性唯一标识了内容类型并建立了层次结构关系。所有 ID 均以父内容类型的 ID 开始，后面是附加的十六进制值。标准内容类型通常包含两个附加的十六进制值，以便为子内容类型创建新的唯一 ID。另一种方法是附带 "00" 和一个十六进制 GUID。举例来说，这就是 Office Data Connection File 和 Universal Data Connection File 内容类型从 Document 内容类型派生而来的过程。

用户需要记住的很重要一点是，ContentType 元素的 ID 属性的长度不能超过 1,024 个字符。如果所有内容类型均采用十六进制 GUID 寻址技术，这在大型层次结构关系中可能会是一个问题。但是，通过缩短长度的方法开始也不是可取之策，因为这些 ID 可能会不唯一。

为确保唯一性，请使用 GUID 技术为企业内容类型建立一个全局命名空间，然后在该命名空间中改用长度更短的方法。有关 ID 属性和其他内容类型定义元素的详细信息，请参阅 WSS 3.0 SDK 中的主题“内容类型定义架构”。

内容类型依赖关系

现在，让我们改为讨论如何使用 SharePoint 内容类型来组织对内容项目的管理。您需要考虑多个依赖关系，如文档库和列表、内容类型、站点列和字段类型之间的相互依赖关系。库和列表引用内容类型、内容类型引用站点列、站点列又引用字段类型（如标准 WSS 字段类型文本、注释、选择项、编号、货币等）、而字段类型又驻留在 Microsoft .NET Framework 程序集中（如 WSS 核心程序集 Microsoft.SharePoint.dll）。

举个例子，让我们返回到 System 内容类型，如先前在 System 内容类型指令清单文件条目的 CAML 定义中所阐述的那样。您将看到，此内容类型包含一个 FieldRef 元素，它引用一个名为 ContentType 的站点列。请注意，内容类型定义并不定义实际的 ContentType 站点列。ContentType 是在 Elements 指令清单 fieldswss.xml 中定义的 Text 字段，该指令清单位于 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields 文件夹中。重申一下，Text 字段类型是在 fldtypes.xml 中定义的，您可在 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML 中找到该文件。对于此依赖关系树，尤其注意必须确保所有资源在 SharePoint 服务器上均可用。

您要使用的内容类型必须是在文档库和列表的站点级别或站点层次结构的较高级别创建的。同样，内容类型的元数据字段必须引用现有的站点列。您可以将基于标准或自定义字段类型的标准或自定义站点列添加到内容类型中，但必须确保这些站点列存在于本地站点内。此外，如果要使用自定义字段类型，则还需确保将基础 .NET 程序集部署到 SharePoint 服务器上。

对于引用文档模板、自定义事件接收器、工作流及其他组件的内容类型，也存在类似的依赖关系。例如，内容类型定义可包含一个指向与内容类型相关联的文档模板的 DocumentTemplate 元素。内容类型定义还可以包含具有一个或多个 XmlDocument 子元素的 XmlDocuments 元素，这些子元素定义内容类型的附加特征，如命名空间定义、文档信息面板定义或任何自定义的信息。

建立全局内容类型

具有编写权限的用户可以直接在 SharePoint 用户界面中创建新内容类型和站点列，但这些内容类型只能供本地站点和站点层次结构下层使用。自定义站点列只能在本地站点中使用。如果您希望建立全局内容类型，则这还不够充分。您需要确保全局内容类型在您的环境中可跨所有站点集合使用。此时，SharePoint 的功能就派上用场了。跨多个站点集合安装并激活 SharePoint 功能以在所有位置统一应用相应的站点列和内容类型定义是一件非常简单的事情。

本文的附属材料中提供了一个名为 AdventureWorks 的示例功能，它演示了如何建立全局内容类型。此功能将定义一个名为 Customer Documentation 的常规内容类型，该内容类型可用于创建任何类型的客户材料（如建议书和销售信函等）。我们可以根据常理来假设所有文档类型都与客户信息（如公司名称、联系人详细信息和地址等）相关联。我还专门为您的内容类型创建了一个名为 Customer Name 的自定义字段，并且还添加了一些内置字段，如 Department 和 Primary Phone。您可以通过编辑附属示例中的 ContentTypes.xml 文件来更改内容类型和字段，通过编辑 SiteColumns.xml 文件来更改字段引用。

如果您按照 readme.htm 文件所述来部署功能，则可跨多个站点集合统一激活该功能。然后，Customer Documentation 内容类型即可供全局使用。这样，各个部门便可通过与目标文档模板关联的派生内容类型来创建特定的客户文档。附属材料包括可用于销售和咨询的示例文档模板。图 2 显示了生成的内容类型。

图 2** 客户文档的父内容类型和子内容类型 **(单击该图像获得较大视图)

在 WSS 3.0 和 MOSS 2007 中，您可以选择使用多种方法来创建自定义站点列和内容类型的功能。您可以研究 WSS 3.0 SDK 然后从头开始编写 XML 文件。您也可以选择使用 SharePoint Designer 将列表导出到个人 Web 包中、将生成的 .fwp 文件重命名为 .cab 文件、从 .cab 文件中提取 manifest.xml 文件，然后在 manifest.xml 文件中搜索 ContentType 定义。遗憾的是，这两种方法都不太方便而且容易出错。

相比之下，在 SharePoint 用户界面中创建自定义站点列和内容类型则非常容易。但是该界面并未提供编辑某个功能的 XML 文件的选项。“功能”是配置 SharePoint 资源的有效方式，但是一经配置之后，资源便仅存在于内容数据库中。或许在 WSS 的后续版本中会包括通过 SharePoint 用户界面将站点列和内容类型导出到 XML 文件中的功能（类似于导出到 Web 部件）。但目前，您需要自行处理此处的内容。

附属材料包括一个名为 ContentTypeSchema 的 Web 部件，它可以用作起始点。它使用 SharePoint 对象模型从所选内容类型中提取 SchemaXML 属性。通过基于可扩展的样式表语言转换 (XSLT) 的转换，Web 部件将派生出 Field 定义或 ContentType 定义，具体取决于您在单击显示按钮前在用户界面中选择的选项。

图 3 显示了这一使用中的 Web 部件。它显示了基于 Customer Documentation 内容类型的 Active Directory® Documentation 内容类型。Active Directory Documentation 内容类型与自定义的 Microsoft Word 模板 (Active Directory Template.dot) 相关联。请注意，此内容类型没有附加字段。所有字段均从父内容类型继承而来。

如果您打算在自己的环境中使用 ContentTypeSchema Web 部件，请记住，此 Web 部件尚未经过全面测试。我的 Web 部件使用了比较复杂的 XSL 转换过程在当前所选内容类型与其父内容类型的 SchemaXML 属性之间构建变化量。但是，XSLT 1.0 实际上并非针对高级 XML 文档转换而设计。不存在用于比较 XML 节点的内置功能。而且，XML 命名空间以及 CDATA 节都是 XSLT 1.0 无法有效进行处理的难题。

SharePoint 将使用 SharePoint 用户界面或 SharePoint 对象模型创建的站点列和站点内容类型的定义存储在内容数据库中名为 ContentTypes 的表内。在图 3 中，请看一下我的自定义内容类型的 ID。下面的 T-SQL 语句将提供相应的确切结果：SELECT Definition FROM ContentTypes WHERE ContentTypeId = <内容类型 ID>。

图 3** ContentTypeSchema 中的自定义内容类型定义 Web 部件 **(单击该图像获得较大视图)

无论决定使用哪种方法，只要获取了站点列和内容类型定义，则为企业范围的内容类型创建功能将是一件轻而易举的事情。建议您对部门或公司的所有全局站点列和内容类型都使用单个功能。这样一来，就可以清楚添加新站点列和内容类型定义的位置。

对自定义元数据执行企业范围搜索

内容类型层次结构最直接的好处是，所有子内容类型均继承父内容类型的元数据字段。由于所有内容类型都共同拥有这些元数据字段，因此对用户而言，在文档库中创建自定义视图和过滤器相当容易。

AdventureWorks 示例功能非常直观地演示了这种情况。无论顾问或销售人员创建的是什么内容，在将生成的 Word 2007 文档保存到文档库时均需指定 Customer Name，因为 Customer Documentation 父内容类型根据需要定义了此元数据。通过根据 Customer Name 来分组或过滤文档库中的项目，顾问和销售团队成员可以方便、快捷地为客户找到所有现有的文档，如图 4 所示。

图 4** 基于公共元数据对库中的各种文档进行分组 **(单击该图像获得较大视图)

通过使用 WSS 3.0 和 MOSS 2007 的搜索功能，公共元数据还使跨多个文档库和站点查找内容变得非常简单。WSS 支持跨单个站点集合内的库、列表和站点进行搜索。MOSS 2007 允许您实施企业范围的搜索中心，并允许您在 SharePoint 3.0 管理中心用户界面中管理自定义元数据，这些都超出了基本功能的范畴。因此，下面将侧重于介绍 MOSS 2007。

当您在 MOSS 2007 中配置共享服务提供程序 (SSP) 并在 SharePoint 站点中爬网时，MOSS 2007 可自动发现在内容源中使用的公共元数据字段。相应地，您可在爬网属性列表中找到自定义的元数据字段。

在 SharePoint 功能中定义的元数据字段通常被归入 SharePoint 类别。要在 SharePoint 管理中心查找其位置，请在“共享服务管理”下的“快速启动”菜单上依次单击指向 SSP 的链接、“搜索”设置、“元数据”属性映射，接下来单击“快速启动”菜单中的“已爬网属性”，然后继续操作，打开 SharePoint 类别。

我将为您提供一个使用中的相关示例。名为 Customer Name 的元数据字段最终成为一个名为 ows_Customer_x0020_Name 的已爬网属性。SharePoint 为已爬网属性添加了前缀 "ows_"，"_x0020_" 是经过编码的单个空格。如果显示此爬网属性的详细信息，您会发现默认情况下它包括在搜索索引中，以使用户可以利用此爬网属性的值来执行内容搜索。但是，为了提高搜索精度，您可能不希望为使用户能够按客户名称来显式搜索内容而将已爬网属性映射到托管属性。

将已爬网属性映射到托管属性时，有两个选项可供您选择。您可以为每个已爬网属性自动生成新的托管属性，也可以手动将已爬网属性映射到托管属性。当您显示所需爬网属性类别的设置时（在类别（如 SharePoint 类别）中显示爬网属性时，单击“快速启动”链接上的“编辑类别”选项），第一个选项可用。在“批量爬网属性设置”下，必须选中“为此类别中发现的每个已爬网属性自动生成新的托管属性”复选框。但是，SharePoint 自动为创建的托管属性添加前缀 "ows_"，并使用 "_x0020_" 来转义空格。已爬网属性 ows_Customer_x0020_Name 的托管属性为 owsCustomerx0020Name。但这不是一个易于识别的属性名称。

或许较好的策略是在部署了企业范围的内容类型后，手动将已爬网属性映射到托管属性。您可以将一个已爬网属性映射到一个或多个托管属性。要在 SharePoint 管理中心创建新托管属性，请在“共享服务管理”下的“快速启动”菜单上依次单击指向 SSP 的链接、“搜索”设置、“元数据”属性映射，然后单击“新建托管属性”，以指定所需信息并将新托管属性与所需爬网属性相关联。

然后，用户可以使用托管属性来定位相关的内容项（可以使用“属性: 语法”的形式，也可以使用高级搜索）。例如，如果要将已爬网属性 ows_Customer_x0020_Name 映射到名为 Customer 的托管属性，用户只需在标准搜索框中指定 Customer: <客户名称>（如 Customer: Contoso），即可搜索该客户的所有文档。

将内容类型中最重要的元数据字段的托管属性包括在“高级搜索”页面上的属性列表中，这也是一个不错的想法。要实现此目的，请显示“高级搜索”页面，然后单击“现场操作”，并选择“编辑页面”命令。现在，您可以单击“高级搜索框”上的“编辑”来选择“修改共享 Web 部件”选项。当您展开“属性”类别并将光标置于相应的文本字段中时，可单击按钮以编辑属性 XML 文档。您需要向 <PropertyDefs> 元素添加一个属性定义，如 <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/>，还需要向 ResultType 元素（例如，元素 <ResultType DisplayName="All Results" Name="default">）下的此属性定义中添加一个引用，如 <PropertyRef Name="Customer" />。图 5a 显示了生成的“高级搜索”用户界面。图 5b 显示了搜索结果。

图 5a** 基于客户名称搜索 IT 基础结构文档 **(单击该图像获得较大视图)

图 5b** 客户名称搜索结果 **(单击该图像获得较大视图)

确保信息一致性

至此，我已成功地对最重要的元数据字段和内容类型进行了标准化，并基于 MOSS 2007 扩展了企业中跨站点集合的搜索功能。现在，当务之急是确保用户在元数据字段中输入的信息准确无误。

有两种方法可实现此目标。第一，您可以使用自定义的 InfoPath® 表单替换文档模板中的标准文档信息面板，该表单为用户提供了预定义的输入选项选择，如列表框中的选择项。第二，您可以将事件接收器绑定到内容类型，然后在用户创建、修改或删除相应的内容项时，检查元数据和其他信息的准确性。

这两个选项相互补充。InfoPath 表单主要提供编辑 SharePoint 内容类型的便利方法，而事件接收器可确保元数据的有效性（即使用户是在 InfoPath 表单外部编辑内容类型属性）。您可将事件处理程序绑定到特定内容类型，这将允许您在所有站点集合中指定与单个内容类型相关联的所有文档的事件及其响应，而不管文档库如何。您可在 msdn2.microsoft.com/ms453149 中找到有关如何开发和部署事件处理程序的详细信息。

将内容类型与自定义文档信息面板进行关联的最简单方法可能是在安装了 InfoPath 2007 的计算机中，在 SharePoint 用户界面上显示该内容类型的“文档信息面板”设置。然后，您可以单击“文档信息面板模板”下的“新建自定义模板”链接，在设计模式下启动 InfoPath 2007。但是，如果您的站点内容类型包括没有明确 SourceID 属性的站点列，则您可能会遇到 InfoPath 无法为“文档信息面板”表单创建有效 XSD 架构的情形。例如，先前引入的 Customer Documentation 内容类型包括多个可能会导致此问题的特定联系人列，如 Department、Office 以及电子邮件，如图 6 所示。

图 6** InfoPath 2007 中 XSD 架构的不兼容性 **(单击该图像获得较大视图)

遇到这种问题时，您可以有两种选择。您可以从内容类型定义中删除对那些没有明确 SourceID 属性的站点列的引用，也可以使用与 InfoPath 2007 兼容的自定义站点列替换那些导致问题的内置站点列。请记住，在将基于 CAML 的内容类型的字段引用配置到内容数据库后，您不能再对其进行更改，尤其是在您已经创建了子内容类型的情况下。您再也不能仅更新一下基于 CAML 的内容类型定义文件，也不能只将更改向下推送到子内容类型，因为 Windows SharePoint Services 并不跟踪对父内容类型定义所做的更改。

要向下推送更改，您必须通过 SharePoint 用户界面或对象模型来更改父内容类型，或者必须定义从现有内容类型派生而来的新内容类型。利用后一种方法，您可以删除关键字段并添加新列。然后，您的用户即可从新内容类型派生以后的内容类型。为防止用户选择错误的内容类型，请将先前的内容类型添加到 _Hidden 内容类型组中。

我在之前曾说过，在部署并激活了基于 CAML 的内容类型后，将无法再更新它们。因此，在部署之前对全局内容类型进行测试显得非常重要。有关详细信息，请参阅 MSDN 文章“更新内容类型”，网址为：msdn2.microsoft.com/aa543504。

创建了具有正确字段引用的内容类型后，您便可以在 InfoPath 2007 中创建自定义文档信息面板。最佳策略是让站点所有者为其子内容类型创建自定义文档信息面板。InfoPath 2007 提供了将自定义文档信息面板直接发布到所选内容类型的选项，这将简化部署方案。它还可以在中心位置（如文档库）发布 InfoPath 表单，并将对文档信息面板的引用包括到内容类型中。如果您打算提供自定义文档信息面板以及 CAML 内容类型，这是最佳的选择。图 7 说明了实施体系结构。

图 7** MOSS 2007 中 XSN 文件在中心位置的实施 **(单击该图像获得较大视图)

本文的附属材料下载中包括一个名为 AdventureWorks_Update 的功能，它通过添加用于 InfoPath 2007 的附加站点列扩展了先前的 AdventureWorks 功能。AdventureWorks_Update 功能将原始的 Customer Documentation 内容类型标记为隐藏并派生出一个名为 Customer Docs 的新内容类型，它使用新站点列来替换继承的内置字段并将新内容类型与自定义文档信息面板相关联。

新的 Customer Docs 内容类型定义包括一个 XmlDocument 元素，它提供有关文档信息面板的信息。具体来说，xsnLocation 元素指向实施文档信息面板的 InfoPath 表单 http://companyresources/DIPs/customerDIP.xsn。有关如何应用 AdventureWorks_Update 功能的详细说明，请参阅 AdventureWorks_Update 文件夹下的 readme.htm 文件。

总结

您可以使用 SharePoint 内容类型来创建元数据策略，并在整个企业中将其统一用于内容管理。利用内容类型的层次结构，您可以标准化与整个企业环境相关的特征，并通过继承方式将其统一用于所有站点。

除此之外，它还可以扩展 MOSS 2007 的内置搜索功能，使用户可以更快速、更方便地查找到特定的内容。它也可以增强与元数据相关的信息一致性并建立集中的信息管理策略。最佳策略是基于最抽象的元数据特征来标准化全局内容类型，从而最大程度减少后续更改需求。SharePoint 内容类型以精心设计的内容模型为基础，可以提供众多新功能来标准化整个企业的内容生命周期管理。

Pav Cherny 是 Biblioso Corporation 的总裁，而且是一位 IT 专家和撰稿人，擅长协作和统一通信方面的 Microsoft 技术。他发表的作品主要侧重于 IT 操作和系统管理方面。

© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.