Re: Comments on LDP TR http://www.w3.org/TR/2013/WD-ldp-20130730/

Tim, we (the LDP editors) were reviewing our first pass at profile 
differences ... where the two classes of implementations you suggested in 
[1] and [2] would vary, and what the new 2119 kws should be.  We realized 
that we were unclear on how far to carry your "don't mess with the 
client's triples" tilt for the generic containers case you were focusing 
on.
It seems likely that letting the server manage membership triples, and 
properties like last modified time on a member, is something that clients 
generally would like.  Likewise, preventing clients from modifying the (LC 
draft names) ldp:membership* values on a container (via which clients know 
what the membership triples are) seems like something that servers should 
be allowed to do.  Both could be heard to conflict with a broad "hands off 
the client's triples" interpretation.  Since the focus of the Sept 3 [3] 
call was on the comments we had in hand [1],[2], we'd like some 
clarification from you on the extent to which your chapter 4 comments with 
respect to letting clients store any triples on the server carries over to 
containers in cases like server-managed properties (modified/created info) 
and membership triples (both the triples themselves and the 
container-level properties that expose the pattern those triples have).
Nested containers will no doubt muddy the waters, but it would help 
considerably if we had more clarity on your intent in cases like the 
examples above.

[1] 
http://lists.w3.org/Archives/Public/public-ldp-comments/2013Aug/0006.html
[2] 
http://lists.w3.org/Archives/Public/public-ldp-comments/2013Aug/0007.html
[3] http://www.w3.org/2013/meeting/ldp/2013-09-03


Best Regards, John

Voice US 845-435-9470