NOTE: Most of this information is historical. For the latest CPIA and Content Model support issues skip to the bottom of this page.

Here's a rough outline of what John and I have requested for Stamping and the Content Model. We have requested that two feature be added to the repository, which will make stamping work really well.

The Issues:

1. How do we represent Stamped Items?
2. How do we streamline access to Attributes of Stamped Items? We often need to fetch an attribute which tells us the attribute that has the data we're interested in.

Proposal:

1. Stamped Items will directly reflect the "bags of attributes" model through adding support for Multiple Kinds in the repository. Once this feature is added, we'll be able to define a EventTask Kind in terms of an Event Kind and a Task Mixin Kind. This feature will probably be very useful in the future, since it reflects the popular notion of multiple inheritance that we use in our Python code.

1. Attribute access will be streamlined through the addition of an Attribute Redirection feature in the repository. Basically this feature allows you to set a flag on an attribute that says "this attribute is a pointer to another attribute". This redirection feature reduces a lot of code, and moves policy decisions out of the code and into the data.

Multiple-Kinds. We want to move towards the Multiple-Kinds (MK) model of Stamped Items because we think this will be best in the long run. However, this requires support from Andi, so we plan to implement an approximation to the feature for use in the near term (the 0.4 timeframe). We propose to rebuild the Trash.ContentModel Schema in a way that will offer a super set of our current Kinds. We'll take the major kinds we use today (Task, Event, Mail, etc) and break them into a Core Data portion (which they all have in common), and a Kind-specific portion (the bag of attributes specific to that kind). These kind-specific portions can then be lumped together using the MK feature. In the near term we'll lump together the combinations that we need by hand. For example, we'll create a EventTask by specifying SuperKinds: Event and TaskMixin.

Attribute Redirection. This feature is best understood through an example. For the Summary View to display the appropriate title for each of it's items it first fetches the "aboutAttribute", and then fetches the attribute that the result points to. This is easily done, and we use a piece of code to do the work for us. The problem is that the association is only known by the code, not by the repository. This will probably present problems in the future when searchs fail because the specified attribute wasn't the real attribute desired. When we change which attributes are redirected, we'll have to change the code, maybe in many places. Also, when we build blocks that automatically display or allow editing of an attribute, we'll have to add code in all these places. It would be much nicer if the repository knew about attribute redirection, and did it for us. This shouldn't be a difficult feature to add, because the respository is already doing something similar for us: it supplies a default value when an attribute is missing. We'd like to explore how hard it would be to add this, or a generalized version, to the repository.

Implementation Details

• Multiple Kinds: Andi has now implemented dynamic creation of a new kind out of multiple existing kinds. He already supports multiple kinds statically, applying rules about how to deal with duplicates (the most recent attribute wins, just like in python). Given the static solution, the Dynamic Multiple Kinds problems boils down to changing an item's Kind from one thing to another, and dealing with moving the attributes across. When maping the attributes, if an attribute goes away then the values associated with that attribute are destroyed. Attributes that exist only in the new Kind simply have no value. If a value is required for the added attribute, then an error is reported. When an attribute exists in both the new kind and the old kind then they must be the same attribute or an error results. The Python class for a Kind that is composed from several super kinds is composed from the classes associated with those super kinds. In other words, the python class gets created (and remembered for later) as you would expect. This dynamic class creation is already in our code -- see mixinAClass.

• Attribute Redirection: Andi has implemented Attribute Redirection as an aspect of an attribute. So when you define an attribute, you define it with a redirectTo aspect in the schema. This works the same way default values for attributes work. This means that Kinds that have one of these redirected attributes never really has value for that attribute; instead when you try to put a value there, it puts the value in the redirected location. When you try to get the value, right before the lookup fails, it sees that the attribute exists in the schema and that it can fetch the value using redirection. So the performance cost of the redirection is only paid for attributes that use this feature, and attribute lookups that fail. This also means that when you iterate through the attributes you may get surprising results. When you iterate through the attributes in an Item, you won't find the redirectTo attribute listed, instead you will find whatever it points to. When you iterate through the attributes in the schema for that Kind, you will see the attribute, but when you fetch its value on an Item redirection will occur. In either case you may end up seeing the value for the attribute that's pointed to listed twice.

-- DonnDenman - 17 Jul 2004

Update for 0.4

Now that we've released 0.4 we're seeing some of the limitations of Attribute Redirection. It only satisfies some of the design requirements for the user interface of blocks like the Summary View. We'd like to see a more powerful mechanism supported by the repository, but we don't yet have a coherent proposal that includes both engineering and user interface design. We need to think through the full implications of this suggestion, and how it would look to the user, before we know if this is what we really want.

The problem in a nutshell is that the attribute to be displayed for a given item isn't constant. For an item of a given kind, it can change over time, or based on the value of another attribute. So we need to either change the redirection on an individual Item (currently redirection is specified on a Kind), or we need to be able to execute some code that determines which attribute to use. Even in the former case we'll need to execute code at certain times to change the redirect on an item as it evolves, so we're leaning towards the computed attribute model. However, computed attributes pose problems for searching, and so they need to be highlighted specially in the UI, so the user knows they are not static attributes.

���* DonnDenman - 15 Oct 2004