Rigid vs Fluid Types

by Vladimir Zlatanov (vlado at dikini net)

Prelude

Both the rigid and fluid types have their place and advantages. A more efficient flexinode-like content type construction will benefit the adaptability of uniform type creation. The vast majority of the use cases will involve creating content of a certain predefined type. On the other hand a fluid objects system will highly enhance possible workflows and possibly lead to interesting reactive systems and workflows.

I would argue that both systems can and should be implemented, but I would implement them separately – the difference between creating a node and enhancing a node via the nodeapi.

The taxonomy system can enhance the behaviour of both rigid and fluid nodes, but it should stay a separate labelling system. In order to assign a behaviour according to the presence of a term or not all you should do is check for it and react. This would allow the building of knowledge based systems. A union of data, classification and behaviour. All you need to do is track the context.

The rigid type system

A rigid type defines a structure of associated elements and their behaviour in different contexts. It should be a design time decision if we are going to support 1-1, 1-*, and *-* association types. The associations are immutable. To achieve this we have to implement the selection mechanisms for the different association types we consider viable, provide a consistent system interface for the system to be successful.

The fluid objects system

It can be implemented as an enhanced nodeapi – filtering for relevant context dependent extensions, regardless of the definition of relevant. This will give the needed flexibility to implement the different schemes and workflows discussed during the last few months all over irc and the web. For example if we implement a taxonomy based relevancy filter, a taxonomy based context or combination of both this will come a long way towards the scenarios described in Drupal Metadata Roadmap.

Taxonomy only for labelling

My hunch is to keep the classification system simple – the taxonomy system should be used for labelling only. It is not its concern to interpret the labels, leave it to the others better equipped to do it. Yes, an enriched taxonomy will produce a flexible metadata system, but it will limit be more specialised, which restricts its application. To achive both goals – implement reasononig for labels.