Meeting Notes -- 05 Jun 2003

When & Where

• Thursday 05 Jun 2003 -- (11:40 to 12:15) and (2:00 to 6:30)
• OSAF office in Belmont

Who attended

• Andi Vajda
• JohnAnderson
• KatieCappsParlante
• BrianDouglasSkinner

Agenda

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

Highlights of what we talked about

• layers
  • we can think of the data model in layers -- (see the diagram from last Thursday's meeting):
    • chandler pim schema (email, appointment, note, task, etc.)
    • tools (enumeration, etc.)
    • schema of schemas (kind, attrDef, etc.)
    • building blocks (item, itemRef, container, etc.)
  • We need an API for the chandler pim schema to use
  • Andi is responsible for the API to the building blocks (XML format to load data)
  • We don't need all the 'tools', but we do need some minimal set
  • There's some disagreement about how big or small the 'schema of schemas' will be
  • Brian will work on formalizing the data model (schema of schemas, tools) in a 'top down' fashion, to meet up with Andi's 'bottom up' view from the repository

• who's doing what?
  • After dev meeting, much discussion about the different layers, ownership, api
  • Before Andi leaves town (in 3 weeks), he has a plan to deliver:
    • XML representation for building blocks: item, itemref, container, etc.
    • Implement building blocks on top of ZODB
    • May work on a bit of schema of schemas, enough to bootstrap
  • John thinks we'll have more clarity if we work through an example: Katie will provide one in the calendar domain.
  • John will be working on a "hello world" example in parallel, to get his head around the problem and start on good developer documentation

• namespaces
  • we might not need namespaces, because items can always be refered to by UUID rather than by name
  • resolution: left this as an open issue for now

• strings
  • Unicode everywhere at the user level, not ascii
  • symbols -- used for python mapping -- ASCII strings with no spaces, etc.
  • Polyglot strings, most likely -- (dictionaries of translations, keyed by language)
  • any string, possibly -- (an attribute of type any string could have a value that was a unicode string, or a polyglot string, or a rich text string
  • more complex types of strings are allowed (all can be represented by ascii), but captured at a higher level (building blocks is unaware of them)
  • rich text strings should be represented in some platform independent way, rather than storing the different platform-specific rich text strings that one encounters on Linux and Windows and Mac

• end user vs programmer
  • The end user wants malleable data, the ability to construct arbitrary views and do interesting searches. The programmer wants objects to use when writing code: some reliance on structure, easy persistence, etc. We've struggled with these two design goals, we've occasionally captured this tension as "item centric" vs "object centric". We could also refer to these two things as the "data model" and the "object system" respectively. It may be a good idea to formally separate attributes (on a given item) into end-user-visible-attributes and programmer-housekeeping-attributes, where there are different expectations for the different types.
  • We will only persist items and their attributes, not random python objects

• types
  • We will try and represent a type as an Item
  • 3rd parties being able to define their own types is a possible later feature, will not be addressed out of the gate.

• delete
  • If you delete an Item, is is truly gone?
  • weak deletion: delete the current version. Yes.
  • strong deletion: delete all versions, the data is not around if you're supoenaed. We may not implement versions at the repository level. No.

• RDF
  • What's our relationship to RDF?
  • We want to be able to express our schema in some sort of RDF (import and export in that format), but it can be a general Chandler-centric RDF, not an RDF designed for interoperation with other apps in specific application domains
  • Chandler application level parcels may want to have their own RDF import/export tools, to express their data in a particular rdf schema (calendar, foaf, dublin core)
  • We do not aim to be a general triple store, capable of storing arbitrary RDF

• UUIDS
  • will the kind item for "Contact" have the same UUID in every repository?
    • resolution: YES
  • will the UUID be a tuple that includes (or encodes) the "home repository" of an item?
    • resolution: NO
  • will different types of datastores each assign their own flavor of UUID?
    • resolution: NO
  • will the client be able to assign its own UUIDs, or does it have to request them from the server?
    • resolution: client can make up its own new UUIDs to assign
  • UUIDs will be randomly generated 128-bit values

• merging items
  • can you take two items that different UUIDs and merge them so that you end up with only a single item?
  • might be desirable from a user's point of view, but implementing this in a general way would be hard

• schema editing
  • can a user edit the Chandler PIM schema?
    • example: Joe adds a new "hair color" attribute definition to the "Contact" kind
    • resolution: NO, all the PIM Schema instances are read-only -- more generally, any schema instance should be read-only if there's ever python code written against it
  • can a user create their own sub-kind of "Contact" and add attributes to that?
    • creates lots of complexity when users start sharing items that come from schemas that were originally related but have been forked

• item versions
  • this is a snake/dragon
  • doing this in a general way could end up being a research project
  • resolution: we recommend that any item version features should be implemented on a case-by-case basis up in the application parcel code, rather than having the repository offer any kind of ubiquitous general-purpose version mechanism for all items

• foreign items
  • we will definitely want to have local copies of items from foriegn data sources (like IMAP mail), in order to handle indexing and querying from within Chandler, and in order to work when off-line
  • we will definitely want to have local copies of items from other Chandler repositories, for example when a user has subscribed to something from somebody else's repository
  • resolutions:
    • this problem will probably end up belonging to whoever is doing replication -- we're going to leave it be for now

• snakes and dragons
  • Sharing data, sharing schema
  • Schema editing, schema evolution
  • Query, indexing (we have some rough agreement, still to be worked out)
  • Versioning. Recommendation: implement this as an application feature, not a general repository feature.
  • Merge/Sync more than two repositories.

• We declared victory (by changing the definition of victory). We have enough of a common picture to do individual work and meet back up again, so today's meeting was the last of the marathon series of six meetings.

Game plan coming out

• Brian
  • update the list of possible data model features to reflect our decisions
  • create a formal representation of a proposed data model
  • arrange a meeting to present our progress and current thinking on the data model and repository

• Andi
  • Start the Python implementation of the data model building blocks. The goal for the first week is to be able to present an XML based format to load items into Python memory and to save them back to XML. This week is the starting point of the implementation of the data model from an object persistence point of view.

• Katie
  • Start working on the calendar part of the pim schema. Have an example ready for the group to walk through

• Brian, Katie, John, Andi
  • Once Andi is in a good spot, meet up again to walk through Katie's example and catch up on Andi's latest thinking. Would be good to have a draft XML format, general proposal for building blocks.

---

• KatieCappsParlante - 05 Jun 2003
• BrianDouglasSkinner - 09 Jun 2003