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

Attempting to net this out somewhat.  Read "we agree" as "since no one has 
yet objected to this point, we agree" ... so object now if you feel 
otherwise.


1:  We all seem to agree that the server's choice of what to in-line is 
not part of the *state* of either the container or the member(s). 

c1a:  The server's choice might be influenced by the state of either, 
especially the #bytes needed to represent either, and this might also vary 
by member.

c1b:  While theoretically possible that the one/both of the states fully 
determines what the server does, we do not feel a need to treat this case 
specially.  I.e. implementation-defined, outside of LDP.

c1c:  Assuming that neither the container's nor the member's state 
determines what gets in-lined (in the general case) leads to an objection 
to options A,B,C from [Arnaud-58], [Pierre-58].



2:  We all seem to agree that the perceived benefits of avoiding "extra" 
GETs  ("protecting the server") is worth spending some spec 
time/complexity on.

c2a:  Absent some additional restrictions on the header proposed in 
[Pierre-58], the "messy potential overlap" between the HTTP request URIs 
and the RDF subject URIs make it impossible for that information to be 
useful to a general HTTP cache in the way we'd like, even if it was aware 
of the the new header.

c2b:  c2a weakens the case for providing member etags on the new header; 
the etags, if added, Would Not be useful for avoiding client GETs on 
members when the client's ultimate intent is to update the member(s) or to 
obtain the representation of the member for purposes other than merging 
into an RDF graph that already includes the container-response's triples.



3:  We all seem to agree that the perceived benefits of lowering the cost 
of "extra" GETs ("protecting the server") is worth spending some spec 
time/complexity on.

c3a:  3 strengthens the case for providing member etags on the new header; 
the member etags, if added, Would still be usable for reducing the cost of 
later client GETs on members when conditional requests are supported.



If the WG believes this is accurate, then the consequences would seem to 
be:

1: [Pierre-58] is the starting point.   I'd propose people use email as a 
straw poll response to doing so (there's nothing magic about Monday 
meetings).

2: (by c2a) we should consider adjusting the "cacheable" portion of the 
header name.  Since I don't enjoying naming parties, I'd propose we do so 
in a separate thread or issue.  Proposals needed.  Leaving it to the 
editors might be one proposal.

3: (by c2b, c3a) we need to decide whether or not to add the etags in the 
header.   I'd propose people use email as a straw poll response, assuming 
we DO add them (in effect we say c3a outweighs c2b).




[Arnaud-58] 
http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0141.html
[Pierre-58] 
http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0049.html

Best Regards, John

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