[Cosmo-dev] Sharing format questions

[Philippe Bossut]

Morgen Sagen wrote:
> 1) There are no "core" attributes -- everything is an annotation.  If 
> I say an item's title is "Foo" and you say it's "Bar" then Cosmo 
> stores both of those values along with their attributions.  It's up to 
> the client to decide whose to pay attention to -- or possibly render 
> both values to the user to decide.
This seems to be rife with issues. 2 users can potentially share an item 
while not sharing any of the attributes... What can sharing mean in such 
a case? Sure, the UI can make this difficult to happen but, still. 
Having some basic core shared attribute for each item seems to be a good 
assurance that such pathological use case will never happen.
> 2) Certain attributes are simply fundamental and have only a single 
> value stored on the server -- core attributes like "title" and "start 
> time".  These attributes are never filtered out when the item is 
> shared.  Other attributes are considered annotations and may be 
> filtered out either by publisher or subscriber.
Seems to be more reasonable.
> Also, I've updated the list below to take into account people's 
> comments from the past day:
>
> - On Cosmo, Items are in a soup, identified by UUID
Are those UUID GUIDs? (global, universal UIDs...). That question has 
been asked by someone else some weeks ago but never answered. My 
understanding is that, yes, those are GUIDs (unique in the knowable 
Universe). This makes merge issues when items are sent around (as 
emails) or shared several times (on multiple Cosmo servers) pretty nasty 
to handle but, well, I think that's the world we decided to live in... 
didn't we?
> - An "Access Control Entry" (ACE) indicates a certain Principal has a 
> given Permission for a given Item
Shouldn't attributes have ACE/ACL also? (e.g. annotation attributes, 
ticklers...)
> - An "Access Control List" (ACL) is a list of ACEs
>
> - There are special items called Tags which contain an ACL
>
> - The Principal who originally PUTs an item to Cosmo is the "owner" 
> and always has full permission to that item regardless of ACLs
>
> - An Item may be "tagged" (associated with existing Tag items) or 
> "untagged" -- actually, what does this mean in terms of the protocol?
>
> - A Principal's access to an Item is determined by iterating all the 
> Tags associated with that Item and examining the ACEs to see if any 
> match that Principal; the most lenient permission wins (Read-write 
> trumps Read-only).  However, perhaps not all Tag ACLs are created 
> equal -- if we relax the restriction on who can tag an item (for the 
> purpose of allowing someone to add a read-only item to their own 
> tag/collection) then we need to ignore certain Tags when it comes to 
> ACLs, otherwise someone could give themselves write access to an item 
> simply by tagging it.  Perhaps only the item's original owner's 
> tagging of an item matters, or maybe there are two levels of tagging: 
> tagging by those that have write-access to an item *are* used to 
> determine ACLs whereas tagging by those who only have read-access to 
> an item are ignored when determining ACLs.
I think limiting the "official tagging" to the "original owner" will 
cripple collaboration scenarios. Tagging by read-access folks should be 
managed like private annotation attributes (assuming we support those, 
see above...).
> - An Item optionally has an ACL which overrides any Tag-related ACLs
>
> - The attributes of an Item fall into two categories: those that are 
> "core" to that Item, and those that are "annotations"; core attributes 
> live in the body of the item's resource, while annotations live in the 
> resource's DAV properties (This depends on how people answer the 
> core/annotation choice I posed at the top of this message).
>
> - A Principal which has Read-only permission to an item may not alter 
> the body of that item's resource, but they may set/remove DAV 
> properties within that Principal's namespace, and they may have some 
> limited tagging ability so they can add a Read-only item to their own 
> tag/collection -- but that shouldn't affect the ACLs of the item.
>
> - A Principal which has Read-write permission to an item may modify 
> the item's resource or delete it, set/remove DAV properties within 
> that Principal's namespace, and add/remove Tags which then affects the 
> item's ACL.  (Note: do we need to limit which Tags can be applied to 
> an item?  For example, if we have an OSAF tag which designates which 
> items appear on the shared OSAF collection, can anyone who has 
> Read-access to that Tag add an item to it?)
>
> - Tags need to be hierarchical, and when examining an item's Tags for 
> their ACLs, super-Tags must also be examined.
My gut reaction to hierarchical tag is "no way": hierarchies have plenty 
of usability issues (to create, maintain, modify, etc...). The success 
of the informal "folksonomies" using tags only is a tribute to the idea 
that non-hierarchical tags are easier to manage. *But*, saying that 
there is no spelled out hierarchies between the tags does not mean that 
there is no structure between them. Such a structure will need to be 
deduced through how the tagged items relate to each other. Segmentation 
techniques should be able to infer a local hierarchy of tags even in the 
most tangled set. Once the local hierarchy is deduced (and appropriately 
displayed), one can imagine to turn "off" a whole node ("work" in the 
example given by Bobby).

This is a different subject, orthogonal to sharing and I should start a 
different thread on this I think (will move it to chandler-dev though 
since some people there are working on auto tagging).

Cheers,
- Philippe