Meeting Notes -- 28 May 2003

When & Where

• Wednesday 28 May 2003 -- 1:30 - 3:30
• OSAF office in Belmont

Who attended

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

Agenda going in

• Bring all the schema/data-model/database people together in one room
• Get consensus on general breakdown of project
• Get consensus on general building blocks
• Figure out what to do next
• Plan to document what we decided and then go do it

Highlights of what we talked about

• Andi presented his proposal for the Building Blocks layer
  • Everything is an Item
    • Items can have Attributes
      • Items are essentially a dictionary of Attributes
    • all Items can be accessed through a UUID
      • this is a globally unique id, unique across all repositories
    • all Items can be accessed through a Path
    • each Item has a "name"
      • the name may or may not be unique within a Container
      • this is not a user-level display name
  • Some Items are Containers
    • a Container is just an Item and has all the aspects of an Item
    • additionally, Containers contain a bunch of other Items
    • Containership is purely for "house cleaning"
      • Containership DOES NOT IMPLY ANY SEMANTICS
    • every Item is owned by exactly one Container
    • when a Container is deleted, all the contained Items are also deleted
  • All semantic references are implemented via Item-Refs
    • Items never have pointers to each other, except via Item-Refs
    • An Item-Ref is an object that is not an Item
    • An Item-Ref can point to an Item, or to another Item-Ref
    • One Item-Ref connects two Items, via two Attributes, one on each Item
  • A Path can be used to identify an Item
    • A Path is a system level thing, not an end-user thing
    • users would not see Paths or type in Paths
    • programmers, doing debugging, might type in Paths
  • Attributes can have Attribute Values
    • some Attribute Values are Literals, like a float or an int or a string
    • some Attribute Values are Item-Refs
  • Conceptually, there are just three things: Items, Containers, and Item-Refs (plus minutia like Attributes, Literals, etc.)

• Then we all discussed the ideas Andi presented
  • Should the "Building Blocks" layer include basic data types, like dictionaries and arrays?
    • yes
  • What types of values can an Attribute have?
    • the "null" value
    • an empty collection
    • some Literal (to include at least: number, string, date)
    • an Item-Ref
    • a "classed" type == a Literal with some associated behavior
    • a collection of any of the above
  • What types of collections would we want?
    • list
    • hash
    • set
    • dictionary
  • Can parcel developers define new Literals?
    • maybe
  • What things are used for indexing?
    • the Schema will explicitly declare what things can be indexed
    • the Schema is in a layer above the Building Blocks
  • Each Attribute has a name. What do those names look like?
    • Each Attribute might have an identifier, with syntax restrictions that would work in Python or Java (e.g. "startDate")
    • Each Attribute might have a display name, which would show up in windows that users see (e.g. "Start Date")
    • Each Attribute might have a URL that uniquely identified it across namespaces
  • Should the repository ensure referential integrity
    • yes

• Then some discussion of strong-typing vs. weak-typing
  • Questions:
    • Can we rely on a "startDate" to always be a date, not just some random text string?
    • Is the user restricted from entering invalid dates? Do we do data entry validation?
    • Does the repository do type checking when it gets a request to store a value?
    • Does some layer of code uniformly do type checking whenever a value is retrieved from the repository?
    • Can a GUI parcel programmer trust that something is what it's supposed to be, or does that person have to do defensive coding everywhere?
    • Should there be some code that does a repository validation sweep, traversing the repository and ensuring that it is valid?
  • Answers:
    • A schema can specify that some Attributes are strongly typed
    • A schema can specify that some Attributes are not strongly typed
    • For strongly typed Attributes, we build the plumbing such that the GUI parcel programmer can blindly trust that the Attribute will never get a value of the wrong type
    • For Attributes that are not strongly typed, an end user is free to enter whatever value they want (e.g. via an tool like the SuperWidget^?)
    • For Attributes that are not strongly typed, when the Attribute Value is stored in the repository, we have to also store something telling us what "type" the value is (e.g. if we store xF800, we need to know whether it's a int or a string)

• Then we talked a bit about RDF
  • general comments about the differences in worldview between the RDF model and the object-oriented programming language model
  • we agree we can easily write some code to export data from a Chandler repository to some kind of RDF doc, as long as we get to pick our own RDF representation
  • but are there other ways that we want to interoperate well with RDF?

• Some discussion of:
  • queries
  • searching
  • Google
  • structured data vs. free-form data

• Some discussion of:
  • the pros and cons of various mechanisms for creating and/or doling out UUIDs
  • the possibly ubiquity of UUIDs (one with every Attribute Value) and the importance of making at least some of them be small (not 128 bytes)

• Goals
  • For 0.2, provide a simple, solid backbone of data handling infrastructure
  • In later releases, add more features

• Block diagram
  • here's a possible way to break down of the data-model/schema into smaller layers

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

Game plan coming out

• John, Andi, Katie, Brian
  • planned a Thursday follow-up meeting to figure out how to decide what features should be provided by the General Schema

• Andi
  • write document with proposal for the Building Blocks layer

• Brian
  • write document with proposal for the General Schema layer

• Katie
  • write document with proposal for the Chandler PIM Schema

---

-- BrianDouglasSkinner - 30 May 2003