Meeting Notes -- 29 May 2003

When & Where

• Thursday 29 May 2003 -- 12:30 - 3:45
• OSAF office in Belmont

Who attended

• Andi -- AndiVajda
• John -- JohnAnderson
• Katie -- KatieCappsParlante
• Brian -- BrianDouglasSkinner

Agenda going in

• follow-up on yesterday's data model meeting
  • move up from the "Building Blocks Layer", and talk about the "General Schema Layer"
• there are lots of open issues in the "General Schema Layer"
  • (for background, see DataModelIssues)
  • we need to decide how (and when) we're going to pick what data model features we want to have

Highlights of what we talked about

• Block diagram
  • building on yesterday's block diagram, Andi suggested adding another layer:

      +--------------------------+   +---------------------+
      | Chandler PIM Schema      |   | Third-party schemas |
      | ("e-mail message",       |   |                     |
      |  "calendar event",       |   |                     |
      |  "address book contact", |   |                     |
      |  "note", etc.)           |   |                     |
      +====================================================+ <-- Repository API
      | Schema Library                                     |\
      | (generally useful items -- e.g. "Enums"            | \
      +----------------------------------------------------+  > "General Schema Layer"
      | Schema of the Schema                               | / \
      | ("Kind", "Type", "Schema", "Attribute Definition") |/   \ 
      +----------------------------------------------------+     > "The Data Model"
      | Building Blocks Layer                              |    /
      | ("Item", "Container", "Attribute", "Item-Ref")     |   /
      +----------------------------------------------------+__/

• categorization
  • we talked about how we might want to categorize the features and issues:
  • categorize by urgency
    1. features that need to be implemented soon (probably for 0.2)
    2. questions that need to be resolved soon, and not revisited
    3. features that we probably want to add later, but which we don't need to think about now
    4. features that we're not going to do and shouldn't ever think about
  • categorize by layer -- in which layer will the feature appear?
    1. Chandler PIM Schema
    2. Schema Library
    3. Schema of Schema
    4. Building Blocks

• transition
  • we started in on categorizing the features/issues, but we rapidly moved from that high-level task down into the more detailed task of actually discussing each feature/issue and trying to decide what we wanted to do about it
  • we decided that the right thing to do was just jump in, and plan on having a long series of meetings (40 hours worth?) to make all the design decisions about what features should be provided by the General Schema

• enums
  • we talked about different options for providing enum support
  • we resolved:
    • the "Building Blocks Layer" should have support for "symbols"
    • the mechanisms in the "Building Blocks Layer" will probably be sufficient to support whatever type of enum representation we used in the "General Schema Layer"

• inheritance
  • we talked about four kinds of inheritance
    • value: an instance inheriting a value from another instance -- similar to derived values -- Andi has found this to be an extremely useful feature
    • attribute: a Kind inheriting an Attribute Definition from a "superclass" Kind
    • type: for strongly typed schemas, when type-checking, an instance counts as type Foo either when it is an instance of the Foo Kind, or when it is an instance of a Kind which is a "subclass" of the Foo Kind
    • behavior: in Python or Java, classes inherit methods from superclasss -- in a database, records do not have behavior -- in our Python mapping for the data model, we will map Python classes to Kinds in the database
  • we resolved
    • to support attribute inheritance
    • to support type inheritance
    • to support multiple inheritance (and therefore also single inheritance)
      • but, to try not to use multiple inheritance in the Chandler PIM Schema
    • to allow an item to be an instance of two kinds
      • but, in the Chandler parcels, not to offer any kind of general data mixing features, but rather in the Chandler PIM Schema, to handle as the E-mail/Task mix as a special case
    • the "Building Blocks" layer will provide the foundation for implementing value inheritance -- we want to talk more about value iinheritance later, when we're also talking about derived values in general -- then we need to decide what support we want to offer for value inheritance up at the level of the "Repository API"

Game plan coming out

• John, Andi, Katie, Brian
  • follow-up meeting tomorrow (Friday) to keep deciding what features should be provided by the General Schema
  • additional follow-up meetings next week

• Brian
  • re-order the data model feature menu so that the higher-priority issues are at the top

-- BrianDouglasSkinner - 30 May 2003