Re: Issue-34 Back_to_Basics proposal

Thanks Arnaud for keeping things moving while I was playing 
whack-(other)-Goths late last week.

> In either case when a member resources is deleted it is removed from
> the collection.

In light of Roger's bug tracker example, which last I looked was not fully 
fleshed out on the wiki, I want to be clear here about what I think this 
case covers.  It covers exactly the message exchanges on the wiki page ;-) 
and may not cover other cases. 

If any collection has what I'll loosely call "special knowledge" about 
other web resources, then the collection is free to use that special 
knowledge to update its membership triples (that is the sense in which 'is 
removed from the collection' above).  A very common case of this is 
exactly the case we've focused on so far: the collection "manufactures" 
new members, very likely shares common implementation with them, and as a 
result "knows" when members are deleted.  As a result, clients have high 
confidence that when a collection gives the a member list that those 
resources will still exist when the client subsequently interacts with 
them.  "High confidence" is simply a nod to timing windows and competing 
requests.  We can and should take advantage of this knowledge where it 
exists.  We might propose to require its use in cases that LDP covers. All 
well and good.

It's *possible* at least in theory that there are other cases where that 
special knowledge cannot be relied upon to exist.  I'm not sure if the bug 
tracker is pushing on some or not yet.  If it is, and we deem what it's 
pushing on to be in-scope for LDP, then we may need to refine LDP.  I've 
taken the approach to try and make incremental progress while this other 
work stream matures rather than assume it will all magically come together 
later.


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario