Re: On ISSUE-58: Property for asserting that complete description of members is included in LDPC representation

> My preference would be for option D (I was convinced by Pierre-Antoine's 
argumentation a few weeks ago). 

Could someone provide a [URL] to some version of that argumentation ?  I 
have a sense it occurred on one of the calls I missed for travel.

In advance of that, I'm hopeful that it tells me what kind of cache could 
use this proposed header and how.
I don't think an HTTP cache would find it useful.  Without knowing which 
subset of the response where the header occurs corresponds to the response 
for each of the asserted cacheable members' contents, I don't see any way 
for a pure HTTP cache (by which I mean one unaware of RDF and LDP) could 
do this, even given the proposed cacheable assertion and matching etags. 
If we talk instead about an RDF/LDP-aware cache, I can see how it Might 
work for storing triples only but as soon as the HTTP response comes into 
it I'm back to it not knowing how to divide up one response into several, 
since the set of triples returned by each HTTP URL can overlap arbitrarily 
in the general case.
There are assumptions under which things are easier (e.g. 1 HTTP URL == 1 
RDF resource, i.e. a given HTTP URL's state consists only of RDF triples 
whose subject URI's HTTP request URI == the HTTP URL lvalue), but that is 
an assumption not anything that LDP guarantees.

Best Regards, John

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