Processing Logic in RIMBAA Applications

Summary

• If one uses the RO cell (of the Technology Matrix), how should/could the processing logic be supported?

Analysis

Grahame pointed out that PL may be done in multiple ways. The extremes are:

• Content driven logic: based on whatever is contained in the data instance.
• Context driven logic: based on the context of the data, e.g. based on knowledge that the data conforms to an InteractionId, a MessageType or Templates.

• See GELLO and RIMBAA blogpost by Ioan Salau for a discussion of the ralationship between GELLO and PL.

Discussion

RO/RS has the advantage of re-uses of one generic bit of code, supports private non-predefined models (ad-hoc RIM objects).

Grahame, in his own application development, uses RO, but uses context-driven-logic (i.e. knowledge that the RO stuff conforms to an interaction - or more particularly, a particular use-case), to process things (and move to the RP or AP cell). By using an underlying RO, I can mix generic and specific use-case driven code seamlessly.

In general, MS/MO is mostly context driven, RS/RO (or, rim-based logic) is mostly content driven.

• This may be because the RIM is a static information model, and that it if it was extended to cover behavioural stuff, that logic would be abstractable? (--Grahamegrieve 20:20, 21 January 2009 (UTC))

MvdZ: I think the cells in the Technology Matrix are different representations of information, so Logic will be in the transition from e.g. MO to MO.

• certainly this is true, but not all the logic is transitions. --Grahamegrieve 20:21, 21 January 2009 (UTC)

Andy Harris: data layer should be context driven (though context may be given by content)