Overview

In this document, we describe the end-user content model for a generic Note , Event, Task and Mail. We also describe how, through stamping an item, an item's end-user visible attributes changes.

This spec builds on Mitch's notes and is meant to elaborate on CreatingNewItemsWorkflow and DetailViewSpec from a content model perspective.

Content Item

When the user creates a generic item (Note), a new content item is created. The following are user visible attributes with the type in brackets when it is not implicitly clear:

Core Attributes

• Created by
• Created on
• Last modified by
• Last modified on
• Contained notes (plain text for 0.4, eventually rich text)
• Triage status (enumeration of Processed/Processing/Deferred)
• Deferred until (date)
• Privacy (boolean)
• @context - not visible in 0.4

Sending/Sharing

• From/Organizer/Requestor ([OI] - more discussions required to model roles and participants)
• To/ Partcipant/Requestee ([OI] - more discussions required to model roles and participants)
• CC:
• BCC:
• Conversation Item

Collection types

• Mailbox
• Calendar
• Contact groups
• Project
• Subject - not visible in 0.4
• Sphere of life
• Adhoc
• Generic (user named collections)

Stamping Requirements

• All Chandler Items (capital I) inherit Content Item attributes above
• Out of the box, the Notes kind has just the Content Item attributes
• The table below lists additional attributes for the main PIM kinds: Mail, Event and Tasks (Contacts are dealt separately).
  • The first column is another way of showing the generic (Notes) content item
  • A generic Item can be stamped to have Mail, Event and Task attributes. Columns 2 thru 4 shows what additional attributes the Item picks up, if just one of the respective stamps was applied.
  • Columns 5 thru 7 shows additional attributes if two stamps were applied. The color shading shows from which kind the additional attributes are picked up from. Task + Event is a notable exception in that it picks up additional additional not present in either Task nor Event.
  • Last column shows attributes for a Item stamped with Mail, Event and Task attributes with the same color shading scheme as above

• A real nice-to-have is to be able to unstamp an item but retain a "memory" of unstamped attributes. Thus, if a user restamps the item, the default values for this newly stamped item retains the previously stamped attributes. For example, say, a Mail was stamped at as an Event with a start time of May 15th 3pm. If it were unstamped as an Event, it visibly loses the start time attribute. However, on restamping the item as an Event, it would be nice that it regains the start time as May 15th 3pm.
• We will probably require more attributes for Mail as we go more in depth into the email application area and communications in general.

Ongoing discussions:

• Linking "From" and "To" attributes to roles from other kinds (Event: organizer, participants; Task: requestor, requestee)
• Modeling "associated documents" (e.g. email attachments) of an item
• Attribute name changes are expected. How do we deal with such flux?

Chao's initial list of attributes to remove from 0.4 focus (to seed discussion):

• all attributes with square brackets [] or "not visible in 0.4" annotation
• recurrence attributes
• tickler attributes
• timezone
• associated documents (e.g. email attachments)

-- ChaoLam - 14 May 2004