rigid types types which have permanent, rigid association
The rigid types establish the metadata at compile or instantiation time.
the Pascal record type – compile time
the C++ class type instatiation time (due to the late binding)
the default Drupal node types, including the flexinode ones are rigid.
fluid types – where the type of an inctance can be changed
The fluid types can change their structure during the lifetime of an instance. Aspect oriented programming techniques come some way down that route.
the typical implementation of the State desigh pattern – search for “GOF state design pattern” for more detail.
the drupal is the nodeapi based extensions– allows the extension of all nodes with extra data or functionality.
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.
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.
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.
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.