Martin Fowler just put up a page on Contextual Validation. I don't feel like adding much to that right now, except to say that FormEncode is built around contextual validation. SQLObject uses FormEncode internally, but still just as contextual validation -- the context there being Python-process-to-database. That means it validates that you put ints into INT fields and stuff like that, or handles encoding or other storage transformations. It doesn't (and won't) validate all your business logic. It won't make sure that passwords are no less than 5 characters long. It won't validate that zip codes fit a certain format. None of that. That isn't storage. I'd argue that isn't even a good model.

Instead FormEncode sees validation as a transformation, as data moves from one place to another. From Python to the database. From an HTML form to your internal structures, and so on. So objects only get validation schemas when they embody some transformation (and SQLObject, as an example, embodies one kind of transformation, but just one).

Now, lest you think this is an academic distinction and overdesign, I should emphasize that this makes your models more useful, your data more agile, the risk of strict validation less risky. This isn't about tying everything down, enforcing absolute integrity. Contextual validation means validating less, not more. But if you are data integrity freak (sorry, enthusiast) you might not like this kind of validation.

Anyway, it's nice to see someone give a name to the pattern, and it's nice to have an authority I can point to if asked to justify the decision.