[Design] Conceptual model for "stamping"

[Phillip J. Eby]

At 03:21 PM 1/21/05 -0800, Mimi Yin wrote:
>I'm going to stay out of the discussion about how the user's mental model 
>of stamping is actually implemented, but I'm going to try to throw in yet 
>another "from the user's perspective" explanation of stamping in the 
>context of extensibility in the hopes that it might clarify things a bit.

Yes, it does.  (Also, I've already officially given up on promoting the 
user model I originally proposed.  I'm now focusing exclusively on how to 
ensure that the implementation of the existing model can be mapped to a 
testable content modelling API that will support ongoing expansion of 
Chandler's content types and capabilities.)

In this message, I'll attempt to show how the action/object distinction can 
be used to organize the API in a way that keeps the user model the same, 
and hopefully addresses Donn's concerns about synchronization and other issues.


>Again, I don't think this changes requirements for implementation. If 
>anything I think it reinforces our original thinking which is that 
>Stamping Kinds or Mixin Kinds, which I actually call Action Kinds on the 
>wiki page are a limited set and non-Mixin Kinds (aka Object Kinds) will be 
>far more prevalent. But perhaps both should be extensible, at least in an 
>ideal world.

The current implementation model isn't particularly extensible, though, 
which is what led me to inquire about this in the first place, and to bring 
up the action item/content item distinction as an attempt at having an 
extensible model.

So, now that you have seen the same distinction, I think a simple way to 
implement it would be just to have Action Kinds not carry any of the 
information that an Object Kind would normally carry, so when you display 
an Action Kind on a to-do list for example, it gets its description from 
the Object Kind it's attached to.  In the degenerate case, what is now a 
Task would actually be a Note (object kind) + Task (action kind).

To put it more concretely, if you look at the EndUserStampingModelSpec page 
and say that a Task now *only* has the magenta fields, and none of the 
white fields, it must have a Note to supply the white fields.  From the UI 
POV, this can be indistinguishable from the current Task type, but 
internally it is more readily extensible to new action kinds and new object 
kinds.  Since there is really only one copy of each kind of field, there 
are no conflicts or synchronization issues between copied fields.

So the overall schema looks something like this:

* ObjectItem has an optional attribute 'actions' with cardinality 'list' 
and type 'ActionItem'

* ActionItem has a required attribute 'object' with cardinality 'single' 
and type 'ObjectItem'

* Both ObjectItem and ActionItem are subkinds of Item

Now, you can have as many ObjectItem or ActionItem subkinds as you 
like.  ActionItem kinds cannot be created independently, however, because 
they must refer to an ObjectItem and have no content values of their own, 
just fields for the action that they superimpose.

That is, you can't create an Event per se, only a note "stamped as" an 
event, if you see what I mean.  I don't think this actually changes any of 
the existing UI scenarios, except insofar as it makes them extensible to an 
arbitrary number of action kinds and object kinds.  After all, in the 
content creation workflows you always start with an empty note and a markup 
bar, right?  So, you'd still do that and it would still look the same, but 
there's a potential to have other kinds added to the markup bar later, and 
you can also have the markup bar work with non-Note content types.

And, for my API use cases, it's now possible to explain to a programmer how 
to create a new object kind or action kind, without any blurring of 
responsibilities across the two.  Queries on action kinds of course need to 
traverse over to the object kind if you are doing a text search, but 
presumably the bulk of action-kind querying is to display things like 
"today's calendar entries" and most needs the action item data anyway.