Meeting Notes -- 01 Apr 2003

When & Where

• Tuesday 01 Apr 2003 -- 1:00 to 3:30
• OSAF office in Belmont

Who attended

• Brian -- BrianDouglasSkinner
• Katie -- KatieCappsParlante
• Mitch -- MitchKapor

Agenda going in

• Walk through Brian's strawman data model.

Highlights of what we talked about

• Topics from the strawman data model:
  • Data model requirements
    • Overall requirements list looks okay. In the right ball-park. Need to identify which requirements are really needed by Chandler.
    • Which features are needed now? -- design for those features now.
    • Which features won't be used in 1.0, and can safely be ignored? -- ignore those for now.
    • Which features won't be used in 1.0, but still need to be thought through now? ("If we don't do it now, then forget about doing it later.") -- think through those issues now.
    • For example, is there any case that has come up yet where we would want to have a Kind-of-Item that subclasses another Kind-of-Item?
  • Terminology: Kind-of-Item vs. RdfClass^? vs. Class
    • Mitch is okay with the name "Kind-of-Item"
  • NULL values
    • Yes, Chandler should support NULL values as distinct from missing attributes
  • UNSET values
    • No, Chandler doesn't need to support UNSET values.
  • Derived attributes
    • Yes, Chandler needs to support derived attributes. But maybe derivation rules can be associated just with Attribute Definitions on each Kind-of-Item, so then maybe we don't need support for individual derived attributes on a per-Item basis.
    • Need to identify how this impacts other parts of the overall architecture.
  • Derived display strings
    • Yes, derived display strings sound reasonable.
  • Sub-attributes
    • Yes, have Chandler support the idea of sub-attributes, without needing explicit support for complex stuff like abstract attributes, or inherited restrictions, or inherited default values.
  • Global attributes
    • Need to identify how this impacts other parts of the overall architecture.
  • Restrictions on attributes
    • Maybe restrictions can be handled as "hints". Hints could be stored in the repository, but the repository wouldn't need to actually enforce the hints.
  • Enumerated types
    • Need to support hierarchical enums.
    • Enums must have a canonical order.
    • Enums may need to have more than one canonical order. Maybe have named orderings.

• Other topics that came up:
  • Design dependencies
    • Need to identify the dependencies between the data model and the other design documents.
  • Design process
    • Need to figure out the process by which the data model gets refined and gets integrated with the overall architecture.
  • Client vs. server vs. middleware
    • Need to figure out the general division of labor between the client, the middleware, and the server.
    • For features like derived values, and default values, and notifications and triggers, we need to figure out what work gets done on the client vs. the server vs. the middleware. The answers to those questions may impact the design of the data model.
  • Things vs. Information Items
    • We talked about the distinction between "Things" and "Items" (or in a different terminology, between "Items" and "Information Items").
    • A Person or a Place is a real world Thing, not an Information Item. Whereas Notes, Event records, E-mail messages, and Contact Items are all Information Items.
    • Things have attributes and are stored in the repository, just like Information Items. Information Items are special types of Things. In the data model, maybe introduce the idea of a Kind-of-Thing, as super-class of Kind-of-Item.

Game plan coming out

• Mitch
  • Plans to talk to Michael about how the data model document fits into the overall development process, and see about mainstreaming the data model document into the process.
  • Plans to get Brian set up as an official volunteer. Will talk to Juergen about creating an OSAF e-mail account for Brian and adding Brian to the staff mailing list. Will see about adding a blurb for Brian on the OSAF People web page.

• Brian
  • Will keep focusing on data model, rather than on the list of possible calendar features.
  • Will keep working on the current data model to-do list.
  • Will start fleshing out all the entries for the various Kinds-of-Items.

-- BrianDouglasSkinner - 02 Apr 2003