Windows SharePoint Services (WSS) 3.0 and Microsoft OfficeSharePoint Server (MOSS) 2007 introduce a new concept known as the Content Type, which provides a better way to manage SharePoint content. See " Windows SharePoint Services 3.0 " for an overview of the framework.
This article introduces Content Types, and explores their features, use, and benefits. This article is based on the RTM release of MOSS 2007.
Introducing Content Types
Content Types enable users to organize, reuse, and maintain the metadata and behaviors associated with SharePoint content, such as a document or a list item.
Consider a SharePoint Portal Server 2003 (SPS 2003) document library being used to store documents, which includes different documents of a project, such as a Requirements Engineering document, the Project Plan, and an Issues List. The SPS 2003 way of organizing this content would be to have separate folders for each type (as shown in Figure 1) or to have a metadata field on the document library itself, which can categorize the document as a specific type.
Figure 1: Organizing content using folders
in SPS 2003.
However, in this approach, we are constrained to having the same set of metadata for all items of the document library. That is, each List can have only a single schema, and each item in the list must conform to this schema. In the scenario described earlier, it would be useful to have a schema for a Requirements Engineering plan as compared to a Project Plan or an Issues List, because these are fundamentally different types of content. SharePoint 2001 had a feature called the document profile, which provided a similar facility, but that was eliminated with SharePoint Portal Server 2003.
Using Content Types, this is now possible in MOSS 2007. A Content Type allows a user to define metadata for a specific type of content. This content type is then associated with the document library or a list. A single document library can be associated with multiple Content Types, thus enabling users to capture the metadata based on the Content Type. This implies that, in MOSS 2007, it is possible for a single document library or list to support multiple schemas by means of having multiple Content Types (this is illustrated in Figure 2).
Figure 2: Using Content Types to get
organized.
This concept also extends to other behaviors, such as workflows, enabling users to also assign a workflow based on the Content Type. Some of the other behaviors associated with a Content Type include document conversion settings and Information Management Policy settings. Figure 3 illustrates and summarizes the Content Type features discussed thus far.
Figure 3: Content Type attributes
and behaviors.
Site Columns
To gain a better understanding of Content Types, it is necessary to understand the concept of a Site Column. This is because the creation of a Content Type requires the use of Site Columns. A Content Type can also be defined as a set of Site Columns.
A Site Column is a column defined at the level of a site and is available for use throughout the site in lists, document libraries, and even sub sites (child sites inherit the Site Columns from parent sites). A Site Column definition comprises a name and data type, along with other attributes of the column such as description, size, and default values. The Site Column creation wizard can be accessed from Site Settings | Galleries | Site Columns; Figure 4 illustrates the Site Column creation UI.
Figure 4: Creating a Site Column.
Creating and Managing Content Types
SharePoint provides the administrative UI for creating and managing Content Types. This can be accessed from Site Settings | Galleries | Site Content Types. The Site Content Types listing lists in one place all the Content Types defined at the Site level, enabling a user to determine if an existing Content Type can be re-used or if there is a need to define a new Content Type. Figure 5 illustrates the Site Content Type Gallery.
Figure 5: The Site Content Type Gallery.
Users can create Content Types by choosing the Create option from the Gallery. Creation involves specifying a name and assigning a group to the Content Type. The group helps to organize the Content Types so they can be located easily. Once a Content Type is created, the user will be provided with the option to set the other attributes and columns of the Content Type, as shown in Figure 6.
Figure 6: Site Content Type management.
The user can then define the actual columns that make up the Content Type by choosing from existing Site Columns or by defining a new Site Column. After the Content Type has been defined, it must be added to a List (or Library). But before a Content Type can be added to a List, the List Settings must be changed to allow the management of Content Types (see Figure 7).
Figure 7: Advanced Site Content Type
management.
After Content Types are enabled on a list, the option to add the Content Types will be available in the List Settings page, as shown in Figure 8. The concluding step would be to add a Content Type to the List using the Add from existing site content types link.
Figure 8: Adding Content Types to a List.
Scope of Content Types
A Content Type is initially defined at the level of a site. Once defined, the Content Type is available to all sub sites within this site. This is called the Site Content Type. Once a Site Content Type has been defined, it can be added to a List. When a Site Content Type is added to a List, a copy of the Content Type is created and added to the List. This copy is called the List Content Type. It is possible to further edit and make changes to the List Content Type; these changes would apply only to the specific List, without affecting the original Site Content Type.
However, if we try the opposite of this and make changes to the Site Content Type, there are multiple possibilities (based on the settings associated with the Site Content Type, as well as the List Content Type). Both the Site Content Type and the List Content Type have certain Advanced Settings that determine the impact of the changes made to the Site Content Type. Let s consider the settings on the Site Content Type first.
The Advanced Settings on the Site Content Type are depicted in Figure 9. (This setting can be accessed by selecting a specific Content Type from the Site Content Type Gallery - http://sitecollection:port/_layouts/mngctype.aspx , then choosing the Advanced Settings option.) The Update Sites and Lists setting controls whether the changes made to the Site Content Type need to be propagated to all the List Content Types that are based on it. A value of Yes implies these changes are propagated to the List Content Types, but the setting on the List Content Type itself also has an impact. Let s consider the settings on the List Content Type as illustrated in Figure 10.
Figure 9: Site Content Type management.
Figure 10: List Content Type management.
(The Advanced Settings for the List Content Type can be accessed by navigating to a specific List and selecting the Content Type from within List Settings, then choosing Advanced Settings.)
The Read Only setting determines whether the changes propagated from the Site Content Type will apply to the List Content Type. A value of Yes implies that the changes would not modify the List Content Type.
Thus, SharePoint provides the maximum flexibility in managing Content Types and it is possible to configure the specific Content Type to accept or reject changes depending on the scenario.
Advantages of Using Content Types
As discussed earlier, the key advantage of having a Content Type is that it allows a single list or document library to support multiple schemas. A Content Type defined at a Site Collection level would be available to all sites created, and, hence, this schema can be re-used as desired.
One of the common scenarios in any evolving Enterprise application is that the metadata associated with it changes with time. Often, applications may have site provisioning frameworks where multiple sites are provisioned based on templates. Although it is easy to define a new template and build newer sites with the new schema, propagating these changes to existing older sites is not an easy task. Content Types have a solution to this problem, as well. The Content Types can be configured in such a way that a change to Site Content Type propagates to all instances of the Content Type within any of the sub sites.
This makes it very difficult when there is custom code that is performing operations on a list or document library. A change in metadata would result in code that must handle multiple scenarios, as the list templates cannot be expected to be consistent across multiple sites. For example, if we added a new field to a list, the older lists would be missing this metadata, so the code would need to be tweaked to handle the situation where some lists have the new field and some don t. Using the concept of a Content Type, it would be possible to define an appropriate Content Type and thus maintain consistency across all sites by propagating the changes.
Content Types support inheritance where it is possible to define certain base Content Types that can be extended to suit a specific scenario. For example, consider a Content Type used to define the training offerings made available by an organization. This Content Type can then be further extended to meet the requirement of a specific sub group where additional properties are added.
At an Enterprise level, the ability to define and control the schema in a central place can be leveraged by organizations in defining and maintaining a corporate taxonomy for the entire organization. Furthermore, it helps to streamline business processes within an organization because it is possible to associate workflows with Content Types.
Conclusion
This article introduces the concept of a Content Type, explains the process of creating and managing Content Types, and details the advantages of Content Types.
Vikram Srivatsa is a software designer working for Hewlett-Packard based out of Bangalore, India.