notes from converations with Ted and Andi

• Ted also has notes on these conversations: http://wiki.osafoundation.org/twiki/bin/view/Journal/TedLeung20040507

sub attributes (attribute inheritance)

• We reached a consensus that we don't want to implement attribute inheritance right now
  • we have alternatives for the two main use cases that we know of right now: event/participant and collection/contentitem
  • we don't think that implementing it later carries a huge amount of risk
  • there is some risk that implementing it now could really slow down other more common cases
  • this feature does not rank high enough in importance to push for it now
• We reached a more clear understanding of how sub attributes would work, if we did implement them
  • You can think of a subattribute as defining a subset of attribute/value pairs.
  • If contentItems have a "membersOfCollections" attribute, then "projects" and "calendars" attributes define subsets of that list of collections. That implies that the superattribute needs to have a list cardinality.
  • The existence of any attribute on a Kind implies the existence of its superattribute.
  • To avoid confusion, each subattribute needs to define its own inverse, and that inverse needs to be a subattribute of the superattribute's inverse.
  • A python class that implements a Kind with a superattribute needs to be able to easiy access all instances of the superattribute/value pairs (all instances of subattribute/value pairs).
• Setting up a bidirectional relationship between two items is most often logically setting up a relationship between two entities. It might be easier to set up that relationship in one place, and not have to define two twin inverse Attributes. Perhaps the parcel xml could support this idea. Sometimes you want to store more data about the relationship (as in the case of event/participant/contact). In this case, we want to use an item to represent the relationship. Perhaps the parcel xml could support this more seamlessly as well.
  • A relationship item should use a well known RelationshipKind, or some subkind thereof. This lets us write code (such as the general table viewer) that treats relationships properly, without knowing the details of a specific relationship.

• A primary benefit for sub attributes is their use in queries/searches.
  • An example from Brian Skinner: Suppose a contact has 3 name attributes: firstName, lastName, middleName. Suppose all 3 have literal values (String), and all 3 are subAttributes of an attribute called "name". Imagine that you search for "all names that include Kim", and that the search looks at all attributes that are subattributes of name, in addition to all name attributes.
  • Generally, the benefit is that you can search an entire class of attributes, instead of listing them individually. This is true for attributes that have itemRef values, or attributes that have literal values.

addressing/extensibility

• Morgen is proposing that parcels have a general mechanism for registering items.
• The extensibility proposal will define particular well known classes of items (probably based on Kind, but might be otherwise). Examples:
  • Kinds and Attribute definitions (which have a Kind of Kind or Attribute)
  • View instance templates defined in parcels (which have a Kind of View)
  • Block and View definitions (which have Kind of Block, View, or some subkind thereof)
  • Capplet instances (which have Kind of Capplet, or some subkind thereof)
• In addition to addressing extensibility concerns, this will enable sort, human readable names for programmers to use to refer to these items in code, instead of using a UUID directly (the names likely map to UUID, so UUID lookup is used under the hood), path or address.
• Although parcels define "instance data", such as OOTB views, the items as defined in the parcel really act as templates. A copy is made to the data space with all other user data: item collections, content items, view instances (which are really trees of block instances), etc. The user edits/customizes this data. (This is the current proposal anyway).

• open issues:
  • We need some namespace/address for actual user data (the current proposal is that this data is distinct from parcel items). One proposal is that we want one location space here: the same as what the user sees (if the user sees this at all), the same as used by webdav, the same one used by cpia programmers, etc. The apps team is starting from the position that this can be unified, but it may work out otherwise.
  • What does this have to do with repository path (parent/child)?
  • If we have a distinct space for user data (vs parcel data that is loaded on startup), what happens when the user defines new Kinds? What happens when the user creates new Attributes, and adds them to existing Kinds? What happens when the user tweaks the ui beyond tweaking view instances?

• Perhaps we want all user authored data in a separate place. This was one of the lessons mentioned by David Jeske in a nice writeup "lessons from a sister project": http://lists.osafoundation.org/pipermail/design/2003-June/002572.html

-- KatieCappsParlante - 10 May 2004