- From: John Arwe <johnarwe@us.ibm.com>
- Date: Wed, 2 Oct 2013 09:22:46 -0400
- To: public-ldp-wg@w3.org
- Message-ID: <OFFD39A963.2CCD6E4B-ON85257BF8.0048CA39-85257BF8.00497F6D@us.ibm.com>
Text from LC draft: 5.6.2 When the LDPC server successfully completes the DELETE request on a LDPC, it MUST remove any membership triples associated with the LDPC as indicated by the canonical Request-URI. The LDPC server MAY perform additional removal of member resources. For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not been accessed for some period of time. Proposed replacement: 5.6.2 When the LDPC server successfully completes the DELETE request on a member LDPR, it MUST remove any membership triples associated with the LDPR as indicated by the Request-URI. Note: The LDPC server can perform additional removal of member resources [HTTP11]. For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not been accessed for some period of time. List of changes - delete request is for a [member] ldpR, not ldpC - triples are associated with the [deleted ldpR, not ldpC] - remove canonical ... very very early feedback from Yves led us to ditch this term and its formal definition in LDP - change all after first sentence to NON-normative, as a restatement of what HTTP delete already allows; as a consequence, MAY >> can Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
Received on Wednesday, 2 October 2013 13:23:19 UTC