Meeting Notes -- 24 Jul 2003

What

• Data Model -- review

When & Where

• Wednesday 24 Jul 2003 -- 3:30 to 8:00
• OSAF office in San Francisco

Who attended

• Brian -- BrianDouglasSkinner
• Andi -- AndiVajda

Agenda going in

• Review Brian's preliminary DataModelSchema work. Get feedback from Andi. Start working on bringing the strawman schema and the repository implementation into sync with each other.

Resolutions coming out

• Weakly typed attributes
  • A weakly typed attribute with cardinality 'single' can be assigned values that are either literals or items.

• Stongly typed attributes
  • An attribute can have a strong-typing restriction to a single 'type' or to a single 'kind'. (e.g. Foo can be required to be an 'int', and Bar can be required to be a 'Contact'.)

• Sets of types for strongly typed attributes
  • An attribute can have a strong-typing restriction, where the restriction allows for a variety of types. For example, on a party invitation, a 'guest' attribute could have the 'type' set to be: "'User' or 'Contact' or 'string'"

• aliases
  • We will have support for 'type aliases'. A type alias is a new type defined in a domain schema, where the new type is simply an alias to an existing type. For example, 'prime number' might simply be an alias to 'int'. An alias can map to more than one type. For example, an 'Entity' might be a 'User', a 'Group', or an 'Agent'.

• strings with chandler links
  • A string can have 'links' to chandler items. The links are not first-class ItemRefs^?. The string is a literal, not an item or a compound attribute. The 'link' is just a character sequence, like an HTML link tag. The link refers to an attribute of the item the string appears in, similar to the idea of the 'display phrase' in the document architecture.

• compound attributes
  • We won't support compound attributes afterall. Instead schema authors will have to just use first-class items, and compound literals.

• compound literals
  • We will support a new feature, compound literals. A compound literal can have a number of 'fields'. Each field can be of some type. For example a compound literal for 'monitary amount' would have two fields, one for 'currency' and one for 'amount': $5. We might use compound literals for different 'date' and 'time' types, or for the notion of a string localization that has an associated langauge code. Each type of compound literal can be bound to an associated Python class that represents it. The fields of compound literal can only be literals, not ItemRefs^?, although a field could have a UUID literal, effectively allowing a unidirectional reference to an Item. (Brian says: it'd be good if these unidirectional item references were a first-class references which supported strong-typing, etc.)

• attribute bindings
  • We will nix the idea of attribute bindings as a way to associate attributes with kinds and keep track of 'aspects' that are properties of the association, like the 'required' aspect. We will use the sub-attribute feature instead, as a mechanism for allowing one Kind to 'override' the aspects that are defined globally for a given attribute definition.

• sub-attributes
  • We will support the idea of sub-attributes, similar to the RDF notion of sub-properties. Each Chandler Attribute Definition can have a set of sub-attributes, which are other Attribute Definitions. Each Attribute Definition can have a single super-attribute, which is another Attribute Definition. A sub-attribute can have the same name as its super-attribute, or it can override the name with a new name. Sub-attributes inherit the aspects of their super-attributes; for example, if a sub-attribute does not have a 'type' aspect, then the type is expected to be whatever type was defined in the super-attribute.
  • We will use the sub-attribute mechanism for two things. One use will be to allow two different Kinds to use a common global attribute, but with different restrictions associated with each Kind. For example, using sub-attributes, a Calendar Event can have a 'start time' which is required, whereas a Task might have a 'start time' which is optional. The other use for sub-attributes is more like the traditional RDF notion of sub-properties. For example, the attributes 'sibling' and 'spouse' might both be sub-attributes of 'family member', but with more specific semantics.

Open issues

• polyglot strings
  • How do we treat a polyglot string as a simple literal?

• heterogenious collections, with both literals and ItemRefs
  • The implementation is difficult, but this may be an important feature. Should we support this feature or not?

• ad-hoc attribute definitions
  • A generic item, with no associated Kind, can have ad-hoc attributes. Some of those attributes might be pre-defined, like the 'start time' attribute used by the 'Calendar Event' Kind. Other attributes will be brand new, and only used by that one item. Do we have Attribute Definition items in both cases?

• strong typing for various string types
  • Should a schema author be able to specify that a string is a single-line string, or that a string does not contain ItemRefs?

• support for heavyweight enums
  • What sort of support will we have for 'heavyweight' enums (meaning an enumeration where each possible value is a first-class item)?

• mapping from lightweight enums to heavyweight enums
  • What sort of support will we have for using lightweight enum strings as keys that point into a dictionary of corresponding heavyweight enum items? For example, using language codes like 'en' as an index for language items that have polyglot display strings with values like 'English', or using currency codes like 'usd' as an index into currency items that have display formats and attributes for name ('US Dollar') and symbol ('$').

-- BrianDouglasSkinner - 28 Jul 2003