Notes

External/Exportable/2-Layer addresses

Some of the requirements seem to be in conflict:

• Short non implementation dependent, human friendly names (for parcel devs)
  • Many of the calls to rep.find will go away once we have queries. The rest could be eliminated by short names for commonly used Kinds. In this context, having nice names for collections that will be used by queries is important
• 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)

I think that we should be looking at names for collections, but no necessarily a perfect hierarchical, filesystem directory like namespace. Every Chandler is going to have a set of basic collections that the user sees. We can use these collections as the roots for exportable addresses

Sub-attributes

Sub-attributes are being discussed in the context of ItemCollections^?, in particular, use of ItemCollections^? by the calendar. The way I understand the scenario, we want to use an ItemCollection^? to implement a Calendar. An ItemCollection^? will have an attribute members, that has all of the members of the ItemCollection^?. When we have a calendar, we want an attribute called events, which is a sub-attribute of the members attribute (which happens to be on ItemCollection^?). The intent is that all items that are in the events attribute are also in the members attribute. So a sub-attribute defines a subset of the items that are in its base attribute.

There are some difficulties. What happens when I ask an Item for a attribute which is a base attribute (by name). The Item in question doesn't have a base attribute (not defined on the Kind - there's another case where the base attribute is defined but hasn't had any data put into it yet), but has an attribute which is a sub-attribute of that attribute being requested. The proposed behavior is that the requestor gets the contents of the sub-attribute. That's fine for reading, but you can imagine situations where the programmer wants to get an error if the base attribute data doesn't exist. So which of the two behaviors is correct? The problem extends to the writing / update case as well. What happens if you attempt to update an attribute which is a base attribute which isn't defined on an Item. There are three possible behaviors: 1) this is an error 2) if the Item has a sub-attribute of the item specified, then modify the contents of the sub-attribute approrpriately (add or update), 3) add/initialize the base attribute, and add the data to it. Again, which of the two behaviors is correct?

The previous set of problems occur whether attributes/references are bi-directional or not. When attributes are ref collections the problems above compund themselves, particularly in the write case. Assume that I write data to non-existent base attribute. Where do we anchor the backpointer, on the sub-attribute or on the base attribute?

In the implementation there is likely to be a performance hit. If you have to check for the presence of a subattribute everytime you do an attribute access/update, then this is much more expensive than just testing the kind to see if the attribute exists.

As far as I can tell, the benefit that we are getting is being able to save a little bit of bookkeeping code because the application doesn't have to track explicitly where all the subsets of a base attributes values are.

Impact on query processing? The query processor will have to do the same kind of attribute search that is done in the read case and take into account any subattributes that may be present.

Are we talking about attribute inheritance or collection inheritance? If reference collections were reified instead of buried, then we'd be talking about combining the values of a "base" collection with the values of its "sub" collections.

-- TedLeung - 27 Apr 2004