Links

• How to make patch file

Notes

Subattributes

There's a bit more to do on this, I missed the following use case:

From Mitch's Notes (http://wiki.osafoundation.org/twiki/bin/view/Journal/MitchKapor20040427):

• Every content item can have one or more participants, which is a contact.
• In the context of an item, a participant can have a role (example: organizer, attendee, requestor)
• With every kind of content item, there can be particular roles.
  • Example: every event can have an organizer
  • Example: every task can have a requestor
• If there is an event "foo" whose organizer is Fred, and a task "bar" whose requestor is also Fred, then content items where Fred is a participant would include both "foo" and "bar" items

The question is how to model this if we don't have subattributes. We need to flesh out the details of how to use relationship items to do this.

Katie clarifies that the role can be implemented using an attribute on the relationship rather than using a sub-relationship. To retreive all content items where fred is a participant, the query will have to know all the role names for a particular relationship. This is a problem because it's not extensible. If I add a new role that should be part of participant, then the query would need to be updated with the new role name.

Perhaps something like this could work:

Kind <- RelationshipKind^? <- Participant

The role attribute is on Participant, and adding a new role value is not a problem because we have all participants. If I want to do a query for only some of the roles then I have to know them to list them in the query. If we need sub sets of a Participant we could add another Sub-kind of Particpant. This partitions the items in Participant (some will be Participants and some will be SubParticipants^?). Then we'd need logic that knew how to reassemble Participants from Participants and SubParticipants^?. This logic needs to live in several places:

1. the code that accesses an attribute which is connected to a relationship item - this is needed to make the access transparent
2. there will probably need to be some code in the query processor so that the correct initial set of items is fed to the query execution engine
3. possibly in the code that handles observable queries, since changes can impact the subset/superset relationship

Addressing

Via http://wiki.osafoundation.org/twiki/bin/view/Jungle/DesignRequirmentsNamesAndAddresses

Additional requirements:

• User-defined names for collections/items. This probably Implies that user defined names have to be resolvable from queries

Process

There is lots of information going into Wiki notebook pages, but it's getting hard to keep everything straight and know whether people have seen stuff that is relevant to them. One thing that we may consider is using some kind of issue tracking system that would let us manage sets of open issues (sort of like a bug tracker, but not tied to software artifacts). I suppose that we could use bugzilla for this. In the ideal case, every spec/proposal would have an associated issues list, and we could know that we were done when we had driven the issues list to empty (assuming that all stakeholders had entered their issues)

-- TedLeung - 10 May 2004