Introducing Content Types

In SharePoint Server 2007, content types remove the dependency between content and lists that exists in SharePoint Portal Server 2003. SharePoint Server 2007 allows multiple document (or object) types in one list (or document library), each uniquely defined by a specific set of metadata and optional settings such as document templates. A document library simply becomes the container in which documents get stored. In SharePoint Portal Server 2003, each list is limited to a single set of metadata (or columns) and a single document template, which makes it hard to deal with heterogeneous documents in the same document library. If you want different metadata associated with your documents, you either use a custom or third-party solution or create a separate document library for each document type, which can lead to administrative overhead. SharePoint Server 2007 has remedied this by decoupling that dependency.

An example of content type usage in SharePoint Server 2007 is the creation of multiple content types in one document library and the application of different document templates for each of those content types. Figure 15-1 shows the differences between SharePoint Portal Server 2003 and SharePoint Server 2007 in the ability to apply different document templates for different content types to a single document library.

Figure 15-1: Multiple document templates per document library

Content types are defined by custom metadata, or list columns. Each content type within a document library has its own unique set of metadata bound to each content type.

Note 

List columns are the containers for the metadata defined for lists, document libraries, and content types throughout SharePoint Server 2007. See the "Configuring Columns for Content Types" section in this chapter for further details on creating and applying list columns to content types.

In addition to using custom document templates for content types, shown in Figure 15-1, you can customize content types further by adding custom settings, such as Workflow and Information Management Policy. Figure 15-2 shows the expanse of settings available to each content type stored within a document library.

Figure 15-2: Content type configurations

Table 15-1 lists the configurable content type properties available through the administrative user interface.

Table 15-1: Content Type Configurations
Open table as spreadsheet

Content type setting	Description
Document Template	The template associated with the content type-for example, Microsoft Office Word or Office Excel.
List Columns	Metadata assigned to the content type.
Workflow	The workflow built in to SharePoint Server 2007, such as approval, that is specific to the content type. [*]
Document Information Panel (DIP)	The top panel, or properties area, of the associated client Office application, such as Word 2007 or Excel 2007, which displays the fields for the corresponding content type metadata when a document is created or modified. The DIP can be customized using Microsoft Office InfoPath 2007.
Information Management Policy	Records policy specific to the content type, such as expiration policy or auditing.
[*]Additional workflow can be created against content types using Microsoft Office SharePoint Designer 2007 and via the SharePoint object model using Microsoft Visual Studio.NET 2005.

Understanding Metadata

To work with content types, you need to understand what metadata is first. Metadata is a set of data that describes a piece of content or a document, and is included as part of that content or document storage. It can include core properties such as the author name, keywords, or comments, and can also include custom properties.

Metadata in SharePoint is applied to content types via list columns. These list columns can then be indexed by SharePoint, and powerful search and filtering queries can be built against the data stored in them. The metadata uniquely identifies and categorizes any document or content related to a content type-for example, expenses might include a list column of Department, while project procurement might include a list column of Project Name. A custom search can then be established to determine all expenses against Department X or on details relating to Project Y. Remember that list columns that are set as optional will not always be populated. If you want to enforce metadata population, set all list columns to require data. This includes any of the default metadata that is included with the default content types, such as Title. To learn how to enforce column data population, see the section titled "Configuring a Required Column" later in this chapter.

More Info 

For information on metadata in SharePoint Server 2007, refer to Chapter 9, "Document Management."

Default Content Types

SharePoint Server 2007 comes with a set of default content types. These default content types are installed at the time of provisioning a site collection and are accessible from the Site Settings Galleries page of the root site of the site collection. For information on how to access this page, see the section titled "Creating a New Content Type at the Site Level" later in this chapter.

Content types can be inherited by the child sites within a site collection and used throughout the document libraries and lists of those sites, or they can be used as the basis for creating new custom content types. Content types at the root level are referred to as the global content types.

Content types are stored and sorted by group. For example, the Document Content Types group includes the Document content type used by the default install of the document library. The Lists Content Types group includes the Announcement content type, used in the Announcements list. When creating a new global content type, you can add the new content type to one of the existing groups or create a new custom group and then add the new content type to your new group.

Table 15-2 shows the default content types and their respective groups, created at the time of provisioning a new site collection and accessible via the Site Content Type Gallery in the Site Settings of the root site.

Table 15-2: Default Content Types and Groups
Open table as spreadsheet

Content type group	Content types
Business Intelligence	Dashboard Page
	Indicator Using Data in Excel Workbook
	Indicator Using Data in SharePoint List
	Indicator Using Data in SQL Server 2005 Analysis Services
	Indicator Using Manually Entered Information
	Report
Document Content Types	Basic Page
	Document
	Dublin Core Columns
	Form
	Link to a Document
	Master Page
	Picture
	Web Part Page
Folder Content Types	Discussion
	Folder
List Content Types	Announcement
	Contact
	Event
	Far East Contact
	Issue
	Item
	Link
	Message
	Task
Page Layout Content Types	Article Page
	Redirect Page
	Welcome Page
Publishing Content Types	Page
	Page Layout
	Publishing Master Page
Special Content Types	Unknown Document Type

Each default content type is preconfigured with default list columns, or metadata. An example is the Document content type from the Document Content Types group. The Document content type is used each time a new document library is created. It includes two list columns: Name and Title.

Note 

Document content types cannot be used in lists, and list content types cannot be used in document libraries.

Understanding the Content Type Inheritance Model

The default content types, referred to as global content types, are located at the root site of a site collection. Content types are created and deployed throughout a site collection via an inheritance model-that is, content types are inherited from content types at the root site, or parent site, level by a child site and used in the site's lists and document libraries. In content type inheritance, the parent content type is the content type from which the new content type was inherited and the child content type is the resultant content type created from the parent content type.

In terms of modifications, each inherited content type is independent of the parent content type. Any custom list columns added to an inherited content type do not replicate back to the parent. For example, you could create a new content type in Site B based on the default Document content type in Site A, and then apply additional list columns to the Site B content type. Changes to that content type will be unique to Site B and can be inherited by any child sites, but not by the parent site, A. The default Document content type from Site A will still be available to all subsequent child sites in its original state.

This inheritance model is depicted in Figure 15-3. Site B is a child site. It inherits the default Document content type from Site A, which is its parent site. Site B creates a new content type, Project Procurement, which includes additional list columns and a custom document template. Site C is also a child site. It inherits the Project Procurement content type from Site B, which is its parent site. Site C then creates a new content type named Project Meetings, which is based on the Project Procurement content type. Project Meetings includes modifications to the list columns and custom document template. Site D is another child site. It inherits the default Document content type from Site A, which is its parent site. Site D then creates a new content type based on the Document content type, Project Expenses, which includes a custom document template. In this scenario, Site D had the option to inherit content types from Site A, its parent site. But if Site D had been a child site of Site C, then it would have had the option to inherit content types from Sites A, B, and C.

Figure 15-3: Inherited content type model

Planning 

If you make changes to the parent content type, you have the option of pushing those changes to any content types inheriting from the parent content type.

New content types are added to either one of the existing content type groups or to a custom group, as shown in Figure 15-4. In this example, the Litware group has been created in the Site Content Type Gallery on the Litware site to contain content types related to the Litware site collection. These include the Litware site, which is the root site, and the Fabrikam and Resources child sites.

Figure 15-4: Custom content type group

The location of each content type is shown in the source column, to the far right of the figure. This location indicates on which site the content type has been created and also the availability of the content type throughout the site collection. In the figure, the Resources location is grayed out and the For Resources content type is highlighted in blue in the site content type column on the left. This is because you are currently within the Resources site, which is a child site of the Fabrikam site. If you navigated back to the Fabrikam site, you would not see the For Resources content type in the Litware group in the Fabrikam Site Content Type Gallery because the Fabrikam site is a parent of the Resources site and content types can be inherited only from parent content types.

When content types are inherited and created on sites, they are within the site scope, referred to as site content types. Content types can also be inherited by the lists and document libraries on a site and modified within the scope of those document libraries and lists, independent of the content type site scope. Those content types are referred to as list content types, or list instances of a content type.

Note 

In describing the content type inheritance model, list content types, or list instances of a content type, should not be confused with the Lists Content Type group, as defined in Table 15-2.

For example, in Figure 15-3 you saw Site B inherit the default Document content type from Site A and create a new Project Procurement content type. The Project Procurement content type includes the default list columns inherited from the Document content type, but it also has some additional list columns. The Project Procurement content type is now available to the document libraries on Site B. In the document library on Site A, you can select the Project Procurement content type and add more list columns to this content type, but you can do so only within the scope of the document library. Changes made to the content type within the document library scope are not replicated back to the same content type in the site scope or other instances of that same content type used within other lists and document libraries on the same site.

Figure 15-5 shows the relationship between site content type and list content type inheritance. Document Library A and Document Library B have each inherited from the Site B Project Procurement content type. The Site B Project Procurement content type is the parent content type, and the Document Library A and Document Library B Project Procurement content types are both child content types, inherited from the Site B Project Procurement content type. Any changes made to the Project Procurement content type in Document Library A does not affect the Document Library B instance of the Project Procurement content type, and vice versa, and changes to either child content type will not flow back to the parent content type. In this case, the list columns for the Document Library A Project Procurement content type have been modified, leaving the Document Library B Project Procurement content type and Site B Project Procurement content type unchanged. At this point, you can choose to update the parent Site B Project Procurement content type and then push those changes to child equivalent content types.

Figure 15-5: Site and List content type inheritance model

Understanding Content Type IDs

Each time a content type is inherited and a new content type is created, the new content type inherits the content type ID from the parent content type. All content types have a unique ID, denoted by a hexadecimal GUID. Content type IDs are limited to a maximum length of 512 bytes or 1024 characters.

You can find the GUID of a content type through the administrative user interface by clicking on a content type link under the Site Content Type column in the Site Content Type Gallery. The resultant URL includes a ctype= parameter. The GUID immediately follows the ctype= parameter and terminates at &Source, for example, ctype= 0x0101000BAD5FF495D8A8640BD3CC6E1D0EB8&source.

The content type ID serves two purposes:

• It identifies the parentage and type of a content type.

• It avoids any duplication or collisions with existing content types-for example, content types created by a developer or third-party content types.

In reviewing the inheritance model of content type IDs, all content types inherit from the System content type, which is denoted by the content type ID 0x. For example, the content type ID of the default Document content type is 0x0101. This number includes the Document content type ancestral relationship up to the System content type, with the prefix 0x. The appending numbers indicate the downward hierarchy, from parent to child. In the case of the Document content type, this includes the Item content type ID denoted by content type ID of 0x01. The default Document content type ID is a child of the Item content type and is uniquely identified by the appendage to the Item content type of 01. The Folder content type is also a child of the Item content type and is denoted by the appendage to the parent Item type of the unique number 20. This hierarchical breakdown for the default Document content type and default Folder content type is as follows:

• System 0x, Item 0x01, Document 0x0101

• System 0x, Item 0x01, Folder 0x0120

Note 

The System content type is sealed and is in a special group named_hidden. It cannot be modified either via the user interface or through the SharePoint object model.

If you create a new content type from the default Document content type, the new content type includes the default Document content type ID of 0x0101 and is suffixed with a unique hexadecimal GUID for the new content type. For example, in creating a Project Procurement content type from the default Document content type, the ID for the Project Procurement content type includes the default Document content type ID 0x0101 plus a unique numerical appendage to uniquely identify the Project Procurement content type: 0009309DA06E3F4143B56078594040953C. Figure 15-6 shows the content type ID hierarchy in creating the Project Procurement content type, where each parent content type ID is appended to each subsequent child content type ID.

Figure 15-6: Content type ID inheritance model