Links

• http://wiki.osafoundation.org/twiki/bin/view/TWiki/TWikiTemplates - how to make a TWiki template -- for these notebook entries I hope.

Notes

Exportable/External/2-Layer Addresses

From a phone conversation with Katie:

A recap of the requirements from http://wiki.osafoundation.org/twiki/bin/view/Journal/TedLeung20040427:

• Short non implementation dependent, human friendly names (for parcel devs)
• Hierarchical names derived from well known rules so that external programs can address chandler items (external nonC apps)
• Browsability by hierarchy (what about use of queries?) (external nonC apps)

and one more that I left out:

• A human readable identifier for every item in the repository

There are three important namespaces:

• Kinds
• Attributes
• Views (these are templates that produce instance level data)

Morgen is proposing that parcels be allowed to register names for their Kinds. I think that we should extend this to Attributes and Views.

This would get us a set of short names that could be used inside Parcels This could also be incorporated as a special namespace in a hierarchical namespace of items

I still believe that we should eschew the parent/child (repository path) hierarchy as the basis for the exportable addresses namespace

The human readable identifier for items still needs some thought. Stuart's WebDAV prototype is using naked UUID's atop an HTTP URI. Unique, yes. Human readable, no.

SubAttributes

Notes from a long AIM chat and a phone conference with Andi and Katie:

There are two primary use cases under discussion:

1. The modeling of the attendee/participant relationship
2. Implementation of ItemCollections

We had a discussion about how to implement Relationships.

1. use an item to represent the relationship (it's linked to the items that represent Entities via bidirectional refs)
2. use ref-collection

We also briefly entertained the notion of literal attributes on ref-collections as an intermediate step, but put that aside.

If we are going to use Items to represent some relationships, we'll define a new RelationshipKind (name TDB) that hides some of the details of accessing the ends of the relationship. This will also help programs like the repository viewer to accurately depict relationships.

As part of the discussion on relationships, we recognized the need for a way to describe bi-directional relationships (either Item based or ref collection based) in a single place (right now you have to do it in several places). This is probably a job for parcel.xml.

We agreed that the best way to implement the Attendee is via a relationship item -- this is because there needs to be additional information associated with the relationship itself. This precludes use of ref-collections.

We also agreed that sub-attributes are not strictly needed for ItemCollections

There's a (another) problem that Andi described where you have an attribute memberOf with two subattributes InCalendar^? and InProject^?. If InCalendar^? and InProject^?'s inverse is the inverse of memberOf, i.e. members, then there will be a problem since members is a set, but the existence of a single item in both InCalendar^? and InProject^? would require it to appear twice in members in order for all bidirectionality constraints to be statisfied.

It should be possible to implement much of the behavior of subattributes by using a naming convention for attributes and the attributes that would have been subattributes and then using reflection along with the naming convention to provide a base class implementation that doesn't need to know about any subattribute a-priori. (MOPs are good).

Decision: will not implement sub-attributes

Rationale (mine): Only one real use case is insufficient motivation to implement such a feature in the data model. We may revisit this later after we get more experiece

Andi's current code for sub-attributes implements the wrong thing and is broken so he and Katie will work to expunge code

-- TedLeung - 08 May 2004