Writing code whenever you want to change the policies associated with a content type can become a tedious operation. It would be better if you could define the more volatile aspects of the policy in an external file and then process that file during execution in order to determine if metadata has been provided consistently and completely. The problem is where should you put the file?
You could certainly put the file in a well-known location, but that would require too much knowledge of the operating environment. What you are really trying to do is separate the policy from your content type implementation so that you can change it more easily.
This section shows how to control the behavior of a class of documents using rules defined in an XML schema associated with a content type. After developing a simple project proposal management schema you create a default policy based on the schema and then attach it to the content type definition. As events are generated by SharePoint during the document revision cycle, you retrieve the policy from the content type and apply the policy.
Referring back to the document lifecycle diagram, you can see how policies will affect the overall document revision cycle. Figure 11-9 shows the revision cycle with policies attached. You want to ensure that the total bid amount for fixed-bid proposals is never less than $5000. On the other hand ...