In the object-oriented world, when I hear the word "sealed" I think of preventing inheritance.  If I create a sealed class named Car, it means that I don't want anyone else to inherit or derive from Car. 

In WSS 3.0, you can create new Content Types that derive from a parent Content Type (e.g. a Car Content Type that derives from a parent Vehicle Content Type).  You can also create sealed Content Types.  You can refer to the Content Type Definition Schema and the SPContentType class for details. 

So what does it mean to create a sealed Content Type?  Not as much as I had hoped.  It turns out that a sealed Content Type is not analogous to a sealed class in OOP.  You can derive a new child Content Type from a sealed parent Content Type.  Let's dig in...

I created a Feature that creates a new sealed Content Type with the following elements definition:

<?xml version="1.0" encoding="utf-8" ?>
<Elements 
  xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentType ID="0x0100AFF5F6F939DB46e2B0FA996BBD1B51FB"
    Name="MikeContentType"
	Group="Mike Content Types"
	Description="A Mike item"
	Sealed="TRUE"
	FeatureId="9BF7D516-A19E-4740-9566-53E1A70EA414">
  </ContentType>
</Elements>

When you go to the edit screen for this new Content Type in WSS, you see the following:

WSS indicates that the Content Type is sealed (in parenthesis in the title). One thing to note is that all of the settings links and column options have been eliminated on this screen. The screen is basically empty.

So let's try and derive a new Content Type from this sealed Content Type. Here is what the new Content Type creation screen looks like:

Notice in the Parent Content Type drop down list that I can select the sealed MikeContentType item. If you click ok and view the child content type, you see this:

The child content type shows the sealed MikeContentType as its parent. "Sealed" isn't so "sealed" in WSS-land.

It appears that the only functionality that a sealed Content Type provides is the ability to lock down a content type's settings. If I modify the sealed Content Type definition to not be sealed, this is what its edit screen looks like:

Now the previously-sealed Content Type can have its settings and columns modified through the UI. It appears as though that marking a Content Type as sealed only prevents editing it through the user interface - rather than preventing inheritance.

This is pretty unfortunate if you ask me. First of all, it's misleading. Second of all, it doesn't appear that you can prevent Content Type inheritance. Neil suggested to me that inheritance could possibly be prevented using a custom policy. You could probably swing that, but I still wonder why the word "sealed" was chosen for out-of-the-box functionality that doesn't appear to have a "sealed" behavior.

del.icio.us tags: sharepoint wss contenttype content type sealed programming oop