Currently, hook_schema only provides the information schema api should know when creating tables. While keeping this tied to database make complete sense, putting some business logic in schema is worth considering.
Table properties:
- One property could tell how a table should act: flat (default), tree (menu, book modules), etc.
- One property could tell if a table should have auxiliar tables, e.g. revisions, node types, etc.
- A set of properties could tell if a table is 'virtual', i.e. it doesn't really map to a table in database, this could be useful to aggregate tables, or to describe webservices and have the benefits of the new fields properties explained bellow.
Fields properties:
- Label (or title): the human readable name of the field, to be used in forms and listings.
- Validation: a field could tell how it's contents should be validated.
- Before saving processing: a field could tell how its contents should be processed before being inserted/updated on the database, e.g. md5() passwords, serialize() array/object data.
- After loading processing: a field could tell how its contents should be processed when loaded from the database, e.g. userialize() array/object data, check_plain() sensitive data, etc.
- Validation, and processing could make use of PHP5's filters.
High level data types:
Another approach would be to bring high-level data types to schema information. Currently, data types are reduced to what databases can understand, what if we could e.g. set a field type to 'email' and let the API handle all the logic to get data validated, sanitized and inserted on the database automatically for us? For core, the list of available types would be small ('email', 'url', 'file', 'date', etc). Other modules could register their own data types. The 'handler' callback for a field would return the data schema api should know when creating the tables. A high-level field could actually create more than one fields on the database, an auxiliary table or none.
Automatic form generation:
With all this information available, automatic form generation would be fairly easy, so on a menu callback that should return a form array, you could get the auto-generated form, tweak it and send for rendering. The API would do most of the validation, processing and saving logic.