- From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Date: Wed, 25 Sep 2013 19:19:38 +0200
- To: John Arwe <johnarwe@us.ibm.com>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CA+OuRR96JsxS5HydTtEaCHAiGtjY7XKsPwDa5ujRPc9ZZynwMg@mail.gmail.com>
Hi John, I see your point better now, and I was probably overinterpreting "membership" here. Revert my -1 to +1. I agree with your last point, though: Webarch is probably a better reference than HTTP. pa On Wed, Sep 25, 2013 at 2:41 PM, John Arwe <johnarwe@us.ibm.com> wrote: > As the change of subject suggests, I'm going to fork detailed > discussions down to 1 rule per thread so it's easier to see when each one > terminates (hopefully in consensus). > > > 5.2.2 - http > > > > -1 : I don't see how HTTP says anything about LDPC membership... > > Plus, as I read it, this point states that LDP clients MUST assume > > that multiple membership is possible. This should stay normative. > > I wonder if you have a different concept of membership in mind, > Pierre-Antoine. > > If by membership we agree that we mean the contents of the membership > triples, and we remember that membership triples can be changed via PATCH > (recommended) or PUT (allowed but discouraged somewhat IIRC) on the LDPC > (as well as by operations on the member resources in the Inverse case), > this reduces back to "any Web resource (including LDPCs A and B) *can* link > TO a resource R, and the link-ers may have no knowledge of one another". > > Arbitrary incoming links is true (of web resources generally), so it was > (and still is, to me) unclear what LDP is adding to that. > > > HTTP is probably the wrong reference for however, there you have a point. > That's probably something else like WebArch. > > Best Regards, John > > Voice US 845-435-9470 BluePages<http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe> > Tivoli OSLC Lead - Show me the Scenario > >
Received on Wednesday, 25 September 2013 17:20:09 UTC