Meeting Notes -- 02 Jun 2003

When & Where

• Monday 02 Jun 2003 -- 1:00 - 3:15
• OSAF office in Belmont

Who attended

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

Agenda going in

• follow-up on Friday's data model meeting
  • keep working through the menu of possible data model features
  • pick which features we want to incorporate, and which to leave out

Highlights of what we talked about

• SuperWidget document data structures
  • John gave us a quick overview of the top-level SuperWidget^? document data structure, as background for talking about display names and thinking about other use cases

• attribute display names
  • some discussion of attribute display names, and whether they belong directly on the Attribute Definitions rather than bundled up with other display info (format, font, etc.)
  • resolved to keep attribute display names as an optional attribute of Attribute Definition items
  • resolved that identifier names should be unique within a Kind
  • resolved that display names should not be required to be unique within a Kind -- we want to be flexible, even though we can imagine this flexibility will make for some headaches later (e.g. with a text-based query language)

• sub-attributes
  • Brian had correctly logged Friday's resolution in Friday's notes, but incorrectly marked it in the menu
  • briefly re-visited topic of sub-attributes, to re-confirm Friday's resolution -- Brian to correct the entry in the menu

• compound attributes
  • resolved to support compound attributes
  • a compound attribute will just be a normal Attribute Definition, but one that has a list of other sub-__Attribute Definitions__
  • the compound attribute will have all the features of a normal Attribute Definition, like "identifier name", and "display name", and "one vs. many" cardinality
  • the sub-attributes will each have all the features of a normal Attribute Definition, like "identifier name", and "display name", and "one vs. many" cardinality

• attributes on attributes
  • example: Spot is a dog. Spot has an attribute called "age". Spot's age is "6". Can "Spot's age is 6" have other attributes, that further describe the "age" of Spot? Maybe attributes like "percent certainty", or "error term" or something?
  • resolution: no

• Item-Refs
  • are there Item-Ref instances -- yes
  • are there "Item-Ref Definitions" that the Item-Ref instances point to -- no

• House-keeping policies
  • discussion of the idea of setting some policy bits that are associated with an Item-Ref, and which dictate how house-keeping chores are done (e.g. how to handle this Item-Ref when cloning or deleting an Item)
  • policy bits are actually kept not on the Item-Ref itself, but on the endpoints of the relationship, at the attributes of the related Items -- more specifically still, the policy bits are actually kept on Attribute Definition items that define the attributes
  • examples of possible policies:
    • copy on copy
    • don't copy on copy
    • delete on delete
    • don't delete on delete
    • delete on loss of last reference

• strong references and weak references
  • discussion of the ideas of "strong references" and "weak references"
  • discussion of reference counting and garbage collection
  • discussion of how "strong references" and "weak references" could be implemented via house-keeping policies like "don't delete on delete"

• referential integrity
  • resolved: when you delete the item at one end of an Item-Ref, the Item-Ref always goes away

Game plan coming out

• John, Andi, Katie, Brian
  • follow-up meeting Wednesday to keep deciding what features should be provided by the Data Model

• Brian
  • update the list of possible data model features to reflect our decisions

---

-- BrianDouglasSkinner - 02 Jun 2003